lasher a écrit 2732 commentaires

OK, je précise :

1. Oui dans les manuels Intel, on a des mots de 16 bits, des double-mots de 32 bits, etc. C'est une terminologie propre à Intel à cause l'ISA qui doit respecter la compatibilité ascendante. Du coup oui, on a des addl, addq générés par défaut pour (par exemple) les architectures x86_64. Dans le contexte du « vocabulaire » d'Intel c'est complètement logique.
2. Quand « je » parle de mots de n bits, je parle de la taille des mots utilisés « par défaut » par l'architecture. Donc certes l'archi x86_64 sait adresser sur des mots de taille 16 bits, mais ce n'est pas la taille « normale » d'un mot sur cette architecture en pratique (je ne sais pas si ma distinction est claire).

Et du coup, Qt réinvente les conteneurs standards […]

Ce n'est pas bêtement dû au fait que la STL n'était pas présente à l'époque et qu'une fois que tu as tes propres conteneurs avec une certaine sémantique, c'est très chiant de tout recoder ?

[…] et n'utilise pas les exceptions

Oui alors ça, c'est un argument assez faible je trouve. Doom 3 n'utilise pas les exceptions non plus…

J'utilise uint*_t lorsque je programme aussi. Mais je parle aussi de « mot de X bits », parce que c'est l'expression « correcte » pour décrire combien de bits sont manipulés à la fois. :) Du coup « byte » vaut TOUJOURS 8 bits dans notre contexte (vu qu'on utilise le terme « mot » sinon), ce qui arrange les choses.

Ce n'est pas ce qu'il voulait dire je pense. Que ce soit en Anglais ou en Français, pour parler de la taille unitaire des données manipulables par un micro-processeur, on parle de « mot de n bits ». Sur un DSP, que le proc travaille sur des mots de 16 ou 32 bits est extrêmement courant. Sur un PC, les mots de 32 ou 64 bits sont la norme; etc.

Sur LinuxFR? Pas trop en fait. La plupart du temps, je vois deux écritures :

1. L'écriture « lâche » : « verbe_en_er t il » → je me mouille pas, personne peut rien me dire, j'aurai qu'à prétexter que j'ai un clavier qwerty.
2. L'écriture « apostrophée » : « verbe-en-er-t'il » ou sa variante « verbe-en-er t'il » → on ne sait pas trop quel est le raisonnement derrière ce choix d'orthographe.

Bon, jusqu'à présent, j'ai remonté ton score parce que bien que n'étant pas forcément d'accord, ça restait pertinent. Là, ta remarque, sur un site comme dflp, je trouve qu'elle est à la limite de l'inutile:

si un auteur n'a pas un avantage direct ou indirect à choisir une licence libre, pourquoi le ferait-il ?

Si tu suis linuxfr depuis suffisamment longtemps, la réponse devrait quand même t'apparaître assez facilement : un mec comme Richard Stallman considérait que rendre les logiciels libres, c'était rendre leurs utilisateurs libres aussi, indépendamment des velléités pécuniaires de leurs auteurs. Comme le disait Kerro un peu plus haut, si l'auteur de la police a été payé sur fonds publics, il serait normal que le public puisse aussi utiliser cette dernière comme bon lui semble. Après tout :

1. On parle d'œuvre immatérielle, la duplication ne coûte rien
2. Ça ne retire pas ses droits patrimoniaux à l'auteur original : on sait toujours qui est l'auteur initial.
3. Si la police plaît, l'auteur peut ensuite être sollicité de nouveau pour en créer d'autres, ou même être payé pour la maintenir (par exemple en incorporant les « patchs » de contributeurs, en traitant les « bugs » remontés par les usagers, etc.).
4. L'auteur peut toujours vendre sa police de caractères ou se faire « récompenser » en utilisant Flattr ou tout autre moyen équivalent !

Ça ressemble quand même fortement à ce qu'on peut faire avec un logiciel libre.

PS: Félicitations, tu es l'un des rares à savoir utiliser la forme en « -t-il » ! :-)

En fait je me dis que tu pourrais proposer tes modifs à l'auteur et lui faire remarquer qu'il serait cool de passer la fonte sous une licence plus libre, et que ça t'aurais permis de la mettre à disposition de suite, tout en lui faisant savoir que tu avais modifié le tout…

… Mhh, je ne sais pas si je suis clair. :-)

Mais si tu n'as pas de bol, et qu'un thread gère des « petites » sommes (exposant n, disons les dépenses quotidiennes), et qu'un autre thread gère des sommes plus grosses (exposant n', disons les salaires ou les chiffres du PMU, ou…), tu te retrouves avec des nombres d'ordres de grandeur potentiellement très différents.

Plus « sérieusement » : j'ai donné des formations sur OpenMP. Forcément à un moment donné j'ai parlé des opérations de réduction. Un bête truc du genre produit scalaire :

/* Algorithme non-optimisé pour le produit scalaire */
void
dotproduct_omp(double * const sumref,                                                       
               double const * const A,
               double const * const B,
               const unsigned long  N)
{   
    double sum = 0.0;

#pragma omp parallel shared(A,B)                                                        
    {                                                                                       
#pragma omp for default(none) reduction(+:sum) 
        for (size_t i = 0; i < N; ++i) {
            sum += A[i] * B[i];                                                             
        }
    }
    *sumref = sum;    
}

#define N 100UL

int
main(void)
{
    double         *A         = NULL, 
                   *B         = NULL;
    unsigned long   n         = N,
                    nbthreads = NUMTHREADS;
    double          sum       = 0.0;

    A = safe_malloc(sizeof(double) * N);
    B = safe_malloc(sizeof(double) * N);

    for (long i = 0; i < n; ++i) {
        A[i] = i;
        B[i] = n-i;
    }

    dotproduct_omp_atomic(&sum,A,B,n);
    printf("Parallel (OpenMP) dot product = %.2f\n", sum);

    free(A);
    free(B);

    return 0;
}

Bien entendu si toutes les valeurs de tes vecteurs sont peu ou prou du même ordre de grandeur, alors pas de problème. Mais si tu as de grandes disparités, même en double précision, alors la version séquentielle et la version parallèle vont sérieusement diverger pour le résultat final — et pas besoin de beaucoup de threads, je crois qu'au-delà de 4 on voyait déjà poindre les ennuis.

Bah, remplace C par Fortran alors. ;-)

Oui enfin, n'importe quel prof un peu sérieux qui te parle de la manipulation des nombres à virgule flottante te dira qu'on ne compare jamais directement deux flottants comme ça :

if (float1 == float2) { // bad programmer, no cookie!
    ...
}

… Mais plutôt comme ceci :

#define DELTA 0.00001
if (float2-float1 < DELTA) {
    ...
}

/* on pourrait meme imaginer une macro: */
#define FLT_CMP(a,b) ( (a)-(b) < DELTA )

Bref, dès qu'on parle de maths avec nombres réels/complexes, on est obligé de passer par quelques précautions élémentaires. Le compilo peut aider pour tout ce qui est calcul sur constantes (mêmes à virgules flottantes), mais l'utilisateur doit faire le reste.

J'aurais dû lire tout le thread avant de répondre tout à l'heure. ;)

Je suis d'accord avec toi sur le fond. N'empêche qu'une bête réduction par exemple, ça peut complètement tuer la précision du calcul final. Donc n'importe quel programme parallèle (pour accélérer ma_compta v2.0 par exemple) risque de tout me casser si je ne passe pas par des entiers ou des nombres de précision arbitraire.

Pas que. Même avec 54 bits, si d1 et d2 ont des exposants très différents, tu vas au devant de gros, gros, gros soucis niveau arrondis…

Tu ne codes ni n'utilises pas trop trop de programmes en Java toi, je me trompe ? :)

Oui enfin, l'une des premières choses qu'on m'a apprise lorsque j'ai étudié ces algos (AES,RSA,etc.), c'était qu'on considérait qu'un secret était « sûr » quand le temps pour casser son chiffrement était suffisamment long pour que le secret lui-même n'ait plus de valeur, une fois la protection cassée.

Struts?

Edit: grillé. :)

Que répond notre auteur face à l’accusation que je lui porte, qu’il cherche – en fait – à faire avancer une certaine conception de la science guidée par un certain système de valeur ?

Je te propose de lui poser la question directement en commentaire, sur son dernier post de blog qui répond à pas mal des commentaires/questions posées ici et ailleurs :

http://toutsepassecommesi.cafe-sciences.org/2013/07/12/reponses-a-quelques-questions-sur-les-ogm-les-bobos-et-la-societe-industrielle/

Ou bien tu peux arrêter de prendre un ton condescendant. La solution de donner les deux prononciations est clairement la bonne et la plus logique. Tout le reste, ça n'est que du « DLFP standard » : trollage annexe sur des points de détails qui deviennent des sous-discussions complètes, etc.

Concernant le karma, etc. : tout ce que tu as à faire, c'est contribuer ailleurs sur le site (commentaires, etc.), et ce de façon pertinente. C'est plus facile s'il s'agit d'une contribution technique : si tu as un avis sur une question technique, il est souvent facile de le valider en récupérant des sources ici ou là pour l'étayer et le fortifier.

Je pense que la question serait « quelle proportion de mauvais marketteux », ce qui inclut aussi le fait que certains organismes marketting ont une voix qui porte plus que d'autres…

Sous win aussi, la majorité des programmes est installée dans 2 répertoires (Program Files), non?

Donc tu as Perl. Donc tout va bien. :)

C'est vrai que ce sont des oui-dires. La personne qui m'en avait parlé est digne de confiance. Après, libre à toi de lui faire confiance à travers moi. :-)

Dans l'article on retrouve quand même pas mal des écueils que les pro-OGM reprochent au anti-OGM, comme jouer sur la sensiblerie des gens, par exemple:

Il utilise une enzyme d’un narcisse (une jolie fleur)

Sauf que là, il s'agissait plus d'un effet comique qu'autre chose… J'irai presque dire de l'ironie. :)

Je ne connais pas le problème du fluor, je constate juste en 2 clics que les bénéfices de l'eau fluoré ne sont pas prouvés

Sauf que justement, il y a d'autres études qui disent le contraire. Par exemple, un journaliste du Scientific American dit que

Cette mesure de santé a été rigoureusement testée depuis 65 ans, et considérée comme la plus grande réussite des cent dernières années, avec la reconnaissance du fait que le tabac est mauvais pour la santé.

Ça m'a pris deux clics aussi, c'était le 3è lien de Google US avec "portland water fluor" comme mots-clef.

La grosse différence avec le golden rice est que ce dernier a coute une fortune en R&D, et apparemment il n'est toujours pas prêt (sinon ou est-il?).

De ce que j'ai compris, si, il est prêt. Simplement le procédé a été raffiné et amélioré (le post de blog parle de 2000 et 2005).

Je suis globalement d'accord avec toi. Cependant j'ai eu des échos d'ingénieurs bossant pour des organismes de type « agence dont le nom est un acronyme à 3 lettres » qui me disaient qu'en gros à l'époque où ils avaient tenté d'avoir accès au code source de Windows (Win2k ou WinXP, si je me souviens bien), MS avait réclamé des conditions tellement extravagantes¹ que les mecs se sont finalement tournés vers Linux.

[1] du genre « le code doit être accessible sur un seul ordinateur seulement, avec une webcam qui permet de vérifier que le mec qui regarde le code ne fait pas de copie illégale » — j'exagère, mais c'était pas si loin de ça dans ce qu'on me racontait.

Sur un desktop (pas un ordinateur portable), j'utilise un trackball, et du coup je n'ai pas beaucoup de mouvements à faire non plus…