alouali a écrit 375 commentaires

Oui ce n'est ni efficace ni précis, encore moins avec les limites physiques du codage interne des virgules flottantes et des entiers, de plus très vite le 4i²/(4i²-1) devient indiscernable de 1.

C'est juste un classique du grand oral de bac, que j'ai pris comme prétexte vu sa petite taille et sa simplicité, pour ressortir le langage C et voir si JavaScript est réellement aussi optimisé qu'on le dit.

Ce qui manifestement vrai, au moins là dessus, puisque je n'ai jamais dépassé les quelques % d'écart, ce qui ne manque pas de m'impressionner.

Les dernières versions avec les remarques apportées ici par tous :

Langage C :

#include <stdio.h>
#include <stdlib.h>
#include <math.h>
#include <time.h>

double now(){
    struct timespec t;
    clock_gettime(CLOCK_MONOTONIC, &t);
    return t.tv_sec + t.tv_nsec /1000000000.;
}


double wallis(unsigned long n){
    double a = 2;
    unsigned long i = 1;
    double t = now();
    for(unsigned long b = 10; b<=n; b*=10){
        for(; i<=b ; i++){
            a *= 4.*i*i/(4*i*i-1);
        }
        double t2 = now();
        printf("%.16f, time=%.3fs\n", a, (t2-t));
        t = t2;
    }
    return a;
}

int main(){
    printf("%.16f\n",wallis(pow(10,9)));
    return 0;
}

JavaScript :

function wallis(n){
    let a=2.0;
    let i=1;
    let t = performance.now();
    for(let b=10; b<=n; b*=10){
        for(; i<=b ; i++){
            a *= ((4.0*i**2)/(4*i**2-1));
        }
        let t2 = performance.now();
        console.log(a, ", time=", (t2-t)/1000.);
        t = t2;
    }
    return a;
}

La version additive, en C, est beaucoup plus lente que la version multiplicative initiale.

Le remplacement du milliard de tests par la double boucle n'a finalement presque rien changé.
Je vais tester le reste des autres optimisations.

Testé à l'instant, hélas le pow(i*2) est un poil plus lent que i*i.

Oui et de la même façon que l'éternité c'est long surtout vers la fin, les puissances de 2 ça devient rare vers la fin aussi 😉

Tu as raison j'avais oublié !
Du coup j'ai corrigé les 2 codes pour les rendre le plus proche possible, l'écart passe à 22% en faveur de C, c'est mieux même si ça ne change pas l'ordre de grandeur.

Ces appels n'ont lieu que 9 fois sur un milliard, ça ne change pas le fait qu'on reste dans le même ordre de grandeur entre C et JS.

Ce n'est une typo, 4.*i*i/(4.*i*i-1) est identique ou un poil plus lent que 4.*i*i/(4*i*i-1). Je suis obligé de garder le 1er 4 en virgule flottante sinon les résultats sont faux ou bien je suis obligé de mettre a = a * au lieu de a *= ce multiplie par 4 le temps d'exécution.

Oui, auparavant c'était iTV, qui a fait une grande grève avant le rachat / transformation par M. Bolloré.

C'est une solution comme ça que je cherche, universelle, puisque toutes les GUI Linux ont un système de notification.

Un livre parfait au croisement de la prise de décision et des algorithmes :

https://www.editionsquanto.org/produit/64/9782889155385/penser-en-algorithmes-poche

Et pour les horaires le site CFF suisse est très léger aussi.

Un jour dans une petite gare à Lyon j'avais un problème de correspondance, l'agent SNCF est allé regarder sur CFF… ça en dit long !

Bravo et merci pour ton pertinent message, moi qui ai subit un énorme déclassement (volontaire) en passant d'ingénieur à enseignant, je constate tous les jours cet énorme mépris de classe, ainsi que l'énorme casse sociale au quotidien (c'est vrai que dans les bureaux on ne la croise pas, dans les classes des collèges publics c'est autre chose).

Je me suis mal exprimé : je voulais dire que si on croit au progrès continu, cela fait partie des indicateurs qui ne devraient jamais reculer, et qu'historiquement ce signal a déjà été le précurseur d'autres reculs.

Bien sûr qu'on peut avoir atteint un palier minimum et être dans la variabilité normale autour de ce palier, bien sûr qu'on ne revient pas avec ce seul indice dans les années 70. Mais en parallèle on a déjà commencé d'autres reculs sociaux et sociétaux, et ces pentes peuvent être considérées comme troublantes.

C'est très mauvais signe je trouve.

Dans les années 1970, Todd en analysant la démographie de l'URSS (La Chute Finale) avait anticipé les 1ers signes de l'effondrement à venir et des mensonges d'état (écart entre les discours et la réalité) en analysant entre autres la mortalité infantile des pays de l'est.

Né à la fin des 30 Glorieuses, il est pénible de se dire que rien n'est acquis et que pas mal de progrès sont à l'arrêt voir même en marche arrière vers le XIXe ou le moyen âge : le progrès social, l'indépendance de la presse, la sécurité sociale, le retour du religieux, les droits des femmes, les inégalités, l'ubérisation …

Du coup je ne sais plus trop quoi penser de mes lectures de l'optimiste Steven Pinker…

La TNT a exactement le même problème.

Pas exactement il me semble :
- TNT : un seul flux pour tous les utilisateurs, le même pour tout le monde au même moment (broadcast).
- Streaming : un flux par utilisateur.

Et pour compléter, si -F te montre une piste vidéo qui t'intéresse en n° 140 et une piste audio en 136, tu fais youtube-dl -f 140+136 http…

Pareil, c'est un de ces vieux trucs qui me font rester sous KDE (et qui me rendent insupportables les retours imposés professionnellement sous Windows).

Par contre je pense qu'on en est à plus de 10 ans, si ma mémoire est bonne on avait déjà ça dans le bon vieux Konqueror !

Merci ! Je vais me plonger dedans !

Complément : je viens de faire le test, j'ai rajouté uid=1000,gid=1000 dans le /etc/fstab et je n'ai plus l'erreur. Par contre les autres utilisateurs continuent à l'avoir.

Merci pour tes réponses, ça commence à rentrer ;-)

Comme tu as l'air plus pointu que moi dans ce domaine, peux tu m'éclairer sur ce point supplémentaire : quand je déplace un fichier de mon ext4 vers une clé USB amovible fat32, cette fois je n'ai pas l'erreur !

Je fais alors mount pour savoir comment la clé a été automontée, la seule différence que je vois par rapport à mon disque archives est qu'il y a en plus uid=1000,gid=1000 qui correspondent à mon utilisateur et à mon groupe.

Si j'ai bien compris, le fait que l'uid source et destination sont identiques seraient la raison pour laquelle il n'y a pas d'erreur ?

Je pourrai mettre uid=1000,gid=1000 dans le /etc/fstab ça règlerai le problème pour moi mais pas pour les autres utilisateurs de l'ordinateur ?

Sisi, je fais l'effort de les lire ! Mais j'ai peut-être aussi du mal à comprendre (ou à accepter) car je ne suis pas très l'aise avec tout ça (j'ai un passé de dev, pas d'admin). Je suis désolé que mes messages et mes réponses donnent l'impression d'être bâclés, car ce n'est pas le cas.

Pour moi vraiment un mv entre volumes c'était égal à un cp + un rm, je comprends donc qu'en fait ce n'est pas le cas et qu'il y a donc 2 algorithmes / stratégies différentes.

J'ai bien compris que le problème ne vient pas des paramètres de montage, mais des types différents des volumes.

Et si j'insiste c'est parce que ce problème ne doit pas être si rare que ça, et que j'ai du mal à croire (ou peut-être à accepter) qu'il n'y ai pas d'autres solutions que de se dire qu'il faut soit subir le message d'erreur à chaque fois, soit faire à la main une copie suivie d'une suppression, parce que c'est vraiment agaçant.

Bonjour,

merci pour ta réponse.

Je suis d'accord, d'un volume à l'autre, un déplacement est une copie suivie d'une suppression.

Mais pourquoi l'erreur n'apparait-elle pas quand on fait un cp, qui lui aussi copie les information de droits ? Un cp est-il moins "exigeant" qu'un mv ?

Et finalement si la solution ne se situe pas dans /etc/fstab, y-a-t'il une autre solution ?

Bonjour,

merci pour ta réponse.

J'ai choisi le format FAT justement pour l'absence de droits utilisateurs, pour que tous les utilisateurs y aient accès en lecture / écriture / exécution (archives de photos, vidéos, fichiers… ainsi qu'une ancienne compatibilité Windows). C'est le disque partagé avec toute la famille.

Effectivement c'est un problème de conservation des droits, puisqu'en ligne de commande, mv source destination me sort un mv: conservation des droits pour « destination »: Opération non permise. Alors que effectivement la même commande avec cp ne sort aucune erreur.

A ton avis y-a-t'il un moyen de contourner ça par d'autres paramètres de montage dans le /etc/fstab ? Avec un umask différent ?

Merci, j'avais pas tilté ;-)