lasher a écrit 2738 commentaires

Lingua::Romana::Perligata—Perl for the XXI-imum Century est ton amie.

Ne pas confondre en français « standard » et « norme ». Le premier implique plus ou moins « de fait » implicitement, alors que le dernier implique une concertation par comité (on dit norme POSIX, pas standard POSIX, même si certaines API ont tendance à avoir été un standard avant, par exemple l'API pour les sockets).

$EDITOR SayLeBien.pm

# SayLeBien.pm
package SayLeBien;
use v5.14;
use strict;
use warnings;

sub new {
    my ($class,$self) = @_;
    $self->{praise} = "Perl, say le Bien!" unless $self->{praise};
    bless $self,$class;
}

sub tell_it_how_it_is {
    my $self = shift;
    say $self->{praise};
}

sub set_praise {
    my $self = shift;
    $self->{praise} = shift;
}

1; # End of SayLeBien

perl -I. -MSayLeBien -e 'SayLeBien->new->tell_it_how_it_is'

Mes parents ont eu 2 Lada il y a loooongtemps (fin des années 80/début 90). La première était pas géniale (porte arrière qui coince, entre autres). La deuxième était certes moche, mais fonctionnelle. Aucun problème à signaler. Accessoirement, les Lada pour les lambda (ha, ha) étaient bof, mais les machins qu'ils faisaient pour le tout-terrain gagnaient régulièrement des prix (4×4, etc.).

Donc Lada by BMW ? Oui, complètement.

Que le caissier ne sache pas répondre à la question, c'est normal. Que son chef (ou le chef du chef …) ne sache pas non plus, je trouverais ça assez ridicule.

Pour le HW, ben faut quand meme se demander pourquoi ils ont suivi Mozilla et pas Ubuntu…

T'es sûr que c'est pas « juste » parce que Mozilla/Firefox c'est une marque connue de tous (car ils ont réussi à s'implanter aussi sur les desktops Windows et Mac OS), alors que Ubuntu pas trop ? C'est peut-être ce que tu sous-entendais, mais mal alors. :-)

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?