Petit résumé et tests dans la réalité

De ce que j'ai compris de tous ces posts:

Decimal('10') * Decimal('1')/Decimal('10') !=Decimal ('1') // ça, pour gUI, ça ferait tâche
Decimal('3' ) * Decimal('1')/Decimal('3') !=Decimal ('1') // ça, pour gUi ça ne fait pas tâche

• C'est totalement psychologique et pas rationnel (sans jeu de mot) pour un sou puisqu'une petite analyse qui prend 30s montre que le cas de la division par une puissance de 10 ne se produit que très rarement. Pour preuve le raisonnement élémentaire suivant:

• les divisions par des puissances de 10 lorsqu'on manipule des mantisses de 13 chiffres, ça a une probabilité d'occurrence d'environ 1/10^{12} soit 20 000 fois inférieure à celle de gagner au loto !!! Mais il s'en fout. Il est d'ailleurs prêt à accepter que python multiplie par au moins 10 le temps de calcul par défaut sur des nombres et gaspille environ 200% d'espace mémoire (un numérateur, un dénominateur) de stockage pour avoir une illusion d'exactitude sur certains résultats (ne concernant qu'une occurrence sur plus de vingt mille milliards possibles).

• gUI est persuadé que python va s'y mettre alors qu'en fait y a juste 4 personnes sur un groupe nommé python.ideas qui se demandent si ça aurait un intérêt (cf le lien qu'il donne). Et visiblement, ceux qui en discutent sur ce forum ne sont pas très enthousiastes (et d'ailleurs il y a très peu de réflexions déposées).

Maintenant passons aux expériences dans la réalité avec un tout petit bench

En python

i=0.0
while i < 100.0:
 i += 0.000375 //utilisation du type float.

time python test.py
real 0m0,063s
user 0m0,035s
sys 0m0,000s

Maintenant en perl6 (attention, ça pique !)

loop (my $i=0.0; $i < 100.0; $i = $i + 0.000375) {}

time perl6 test.pl
real 0m10,449s
user 0m8,648s
sys 0m0,012s

Soit une performance divisée par 175 par rapport à Python !!! Rien que ça :)
L'avantage d'avoir manipulé des décimaux (ou des rationnels, on ne sait pas), c'était quoi ? Le choix de passer par ce type rationnel était totalement absurde, et en plus il a été fait par défaut.

Beaucoup plus intéressant encore: en perl5, ça donne quoi actuellement ?

for (my $i=0.0; $i < 100.0; $i = $i + 0.000375) {}

time perl test.pl
real 0m0,216s
user 0m8,171s
sys 0m0,06s

Autrement dit, le passage par défaut en decimal, a objectivement donné une exécution 48 fois plus lente (j'étais pas si loin quand je disais 50).

Tout ça dans quel intérêt au juste ? Absolument aucun.
A ce sujet, le dev qui s'est chargé de ça intervient ici https://stackoverflow.com/questions/46840840/does-perl-6-performance-suffer-by-using-rationals-for-decimal-numbers pour répondre à une interrogation tout à fait fondée et répond, sans bench à l'appui, que "grosso modo" ça n'a que peu d'impact (bah voyons !). Pourtant, toujours sur cette page, le seul retour d'utilisateur est un gars qui explique l'explosion du coût de calcul (rien que pour le module de passage aux strings à l'affichage).

Petite remarque

En Ada avec la virgule fixe (donc sans aucune approximation via une abstraction au dessus de float) le même test donne

procedure fix is
 type my_real is delta 0.000_375 range 0.0..100.0;
begin
 for e of my_real loop null; end loop;
end fix;

real 0m0,002s
user 0m0,007s
sys 0m0,000s

Sans appel. Il aurait peut-être été bon que le gars qui s'est occupé du passage au type Rat par défaut chez perl, fasse un petit bench et explique l'intérêt de diviser les perfs par 50 pour éviter de faire "tâche" dans une proportion d'un calcul sur 1000 milliards. Il reste toujours la possibilité d'utiliser perl5 ;)