Dr BG a écrit 3463 commentaires

objectivement donné une exécution 48 fois plus lente

Pour être tout à fait juste, Perl6 n'a pas grand chose à voir avec Perl5, c'est une implémentation totalement différente, donc la différence de perf peut tout à fait venir d'autre chose.

Mouais, tu dis quand même que c'est chiant (« Le pb c'est que le programmeur à priori ne sais pas si il aura affaire à un Décimal ou à un flottant, et là ça fait pas trop plaisir en général »), mais que c'est pas grave (« Il peut toujours récupérer le signal de perte d'exactitude, il saura qu'on a basculé (ou tester le type()) »).

Dans un langage impératif, changer de type suivant le résultat ne me semble pas une bonne idée, le programmeur ne peut plus prévoir ce qu'il va obtenir à la fin.

Perso, je ne l'ai pas moinsé, mais il n'a aucun intérêt.

Le calcul est sur des float, et donne le bon résultat dans l'arithmétique des flottants. Si tu veux utiliser des décimaux, il faut le dire, mais pourquoi les utiliser par défaut ? Après tout on veut peut-être des rationnels (encore plus lourd), ou carrément du calcul formel (encore vachement plus lourd) puisque tous les réels ne sont pas représentables.

Histoire de préciser ma pensée : je t'ai donné un exemple avec des décimales. Maintenant, tu fais
>>> a = Decimal('1') / Decimal('3')
>>> a - a
Decimal('0E-28')

Aïe, c'est pas 0, ça la fout mal. On a ralenti les perfs, et encore pour faire de la merde. Bon, les décimaux ça ne suffit pas, on passe au rationnels (en perdant encore de la perf aux passage) ? Ok, ça marche sur mon nouvel exemple, alors faisons un petit calcul similaire impliquant racine carrée de 2… zut, encore foireux. On s'arrête où ? C'est dommage de ne pas pouvoir faire des calculs sur les réels, mais c'est comme ça.

La solution à mon pb existe AUJOURD'HUI

Elle existe pour cet exemple-là, mais tu trouveras toujours des exemples foireux.

en général on se fout de la perfo

Non, dans la majorité des cas, on s'en fout de plus de précision.

Sans compter le fait que quelque soit le système choisi pour augmenter la précision, il y aura des calculs qui ne seront pas exacts. Si on compte sur le fait que deux variables représentant des réels sont censées être égales, on risque des bugs.

>>> from decimal import *
>>> Decimal('2') - Decimal('1.8') - Decimal('0.2')
Decimal('0.0')

Non, ce n'est pas une erreur de calcul. Le résultat est exactement celui attendu dans le cadre d'un calcul en flottants. Si tu veux un autre type de représentation des nombres, eh bien tu les utilises !

Je pense qu'il y a mieux à faire

Je t'en prie, fais-le et devient le nouveau Bill Gates (pour ce qui est de la fortune).

Sinon, comme tu as pu le lire dans d'autre commentaires, bien-sûr que ça se fait, mais seulement quand on en a besoin (rarement) parce que c'est coûteux.

Oui, on paye des assurance anti-fraude, mais la banque doit cotiser plus si elle se fait avoir souvent! donc elle préfère fâcher quelques clients et maintenir les bénéficies de ses actionnaires.

Hé bien même pas. Il me semble qu'en cas d'utilisation frauduleuse, ils annulent la transaction et c'est donc le commerçant qui paye…

Je suis chez Crédit Mutuel avec une carte MasterCard. Je ne pouvais pas effectuer un achat à 0€ chez Heroku. J'ai téléphoné, et ils m'ont dit qu'un service à Sans Francisco c'était louche, que ça ne devait pas être très connu. Ils ont débloqué ma carte après mon coup de fil.

Bref, pour se prémunir de toute fraude, ils se permettent de couper un service que l'on paie (et on paie même une assurance en cas de fraude…) avec des règles automatiques à la con. Ils ne m'avaient d'ailleurs pas prévenu qu'ils avaient bloqué ma carte.

C'est surtout qu'il vaut mieux parler distinctement avec un accent français bien identifié qu'un faux accent pourri anglais ou américain. J'ai déjà entendu des gens qui en rajoutaient un peu trop dans la caricature d'accent américain à manger leurs mots que c'en était ridicule (et pas forcément compréhensible). Après c'est sûr, c'est mieux d'avoir un bon accent.

L'utilisateur s'en fout que rpm soit utilisé par dnf, du moment qu'il n'a pas à utiliser rpm directement. Ce qu'il veut dire, c'est que sous Debian, certains cas ne sont pas gérés par apt et tu DOIS utiliser dpkg, alors que sous Fedora, tu peux t'en sortir avec dnf.

Ça me fait penser à un conseil scientifique d'un établissement que je ne citerai pas, où certains directeurs de labo se plaignaient de leur mauvaise évaluation. Ils ne se plagiaient pas que les critères étaient mauvais (ce qui est fort probable), ils ne se disaient pas non plus qu'ils n'avaient peut-être pas bien bossé (ce qui peut arriver). Non, ce qui les gênait était de ne pas connaître les critères à l'avance.

Comme quoi, ce qui compte, c'est de coller aux critères.

Justement, ce qui est problématique, c'est que dès qu'un train est en retard, ça entraine des retards en chaîne sur l'ensemble du réseau. Et ça par contre, ça peut s'optimiser.

Hé bien c'est exactement ce que je dis, c'est ça qui est optimisé. Mais ça n'empêchera pas ton train d'être en retard car il y a eu une panne.

Je ne veux pas dire extérieur à la SNCF, mais plutôt qui n'a rien à voir avec les algo de régulation du trafic. Il s'agit de problèmes difficilement prévisibles.

ils connaissent la solution pour que les trains ne soient plus en retard.

Ce n'est pas possible car c'est bien souvent le fait de problèmes extérieurs. Mais je sais qu'il appliquent des méthodes d'optimisation pour réduire l'effet d'un retard. Ensuite ces problèmes sont extrêmement compliqués et la solution n'est souvent pas unique, il y a donc des choix à faire sur les objectifs à prioriser.

En tous cas les choix n'ont rien d'irrationnels.

La SNCF embauche des gens pour faire de la recherche opérationnelle sur les problématiques de retard de train, donc j'imagine que la solution, ils la connaissent.

il n'y a rien de rationnel à bloquer plusieurs trains (et leurs usagers, hein, je suis jamais tout seul dedans) pour un seul

Bien sûr que si.

S'il y a beaucoup de personnes en correspondance, le retard moyen d'une personne sera peut-être largement réduit. Cela dépend du retard, mais il n'est pas irrationnel de faire perdre 5 minutes à certaines personnes pour éviter d'en faire perdre 60 à d'autres.

J'aimerais simplement pouvoir attribuer un onglet ou groupe d'onglet messagerie et avoir une sous couche de "Thunderbird" à l'intérieur de FF, je ne vois pas ce qu'il y a de ridicule.

Oui mais pourquoi ? Et dans ce cas pourquoi pas un onglet « lecteur vidéo », « gestionnaire de fichier », « IDE » etc.?

Peut-être parce que tout le monde trouve normal qu'un plombier puisse bien gagner sa vie?

Pour ma part c'est surtout que j'entends beaucoup de fantasmes de certaines personnes qui se disent envier les gens qui ont un boulot manuel parce que ça rapporte bien et qu'ils n'ont pas fait d'études… Quand je regarde les membres de ma famille, c'est très loin d'être la réalité, ou alors on parle de l'artisan qui gère son entreprise, mais dans ce cas, c'est un salaire de patron.

Appeler le C de faute professionnelle, c'est un peu fort quand même. Dans ce cas je dirais que tout le monde devrait être au chômage.

Tu devrais peut-être relire son commentaire, car il ne dit pas ça.

Par ailleurs, indépendamment de Go, le langage, qui n'a aucun intérêt ou presque, il y a des choses intéressantes dans Go, en particulier l'idée que finalement on peut rendre un langage bof très agréable à utiliser si on met le paquet sur les outils. C'est hors du cadre discuté dans mon journal ci-dessus

C'est exactement la réflexion que je me faisais, mais je m'abstenais de commenter car ce n'est pas exactement le sujet de ton journal.

J'ai beaucoup d'affection pour les langages comme OCaml, mais je ne l'utilise que très (très) peu car le manque d'outil est frustrant par rapport à un langage comme Java.

Les taxes sur les transactions boursières sont en effet une piste.