Approximation de résultat avec MAY - Page 1

yop,

Je vérifiais les opérations des enfants, puis mes propres vérifications avec MAY.
J'ai tapé :
97839.78*8.76
Résultat exact : 857076.4728
Résultat affiché par MAY : 857076.4729999999E5

Est-ce une question de paramétrage que j'ai mal fait, ou est-ce que MAY devrait afficher un résultat exact dans ce cas (puisqu'il existe) ?

ça vient peut-être de la représentation des flottants qui, elle, est approximative.

Tu as demandé à travailler avec une arithmétique flottante en base 2.
Cette arithmétique ne permet pas de représenter 97839.78 ou 8.76 de manière exacte : une approximation a été faite pour les représenter en base 2.

Si tu veux un résultat approché exact, utilise la commande approx qui s'occupe de gérer tous ces problèmes d'approximation pour finir une approximation à 10^-N garantie (où N est le second paramètre) :
$ 97839.78*8.76
8.5707647279999999E5
$ approx(97839.78*8.76,10)
8.570764728E5
garantie dans la limite des bugs

Bah, c'est pour ça que TI calcule en BCD…

Et il est impossible de garantir un arrondi décimal correct avec des flottants binaires.

Par exemple:
1/20 = 0b0.00001100110011…
1+1/20 = 1.05 = 0b1.00001100110011…

Mettons que tu calcules avec 8 bits de précision (mais si tu en mets plus, on peut trouver d'autres nombres problème, il suffit de changer ce qu'il y a devant la virgule). Alors en binaire, tu obtiens:
1/20 ≈ 0b1.0000110
Maintenant, mettons qu'on te demande 2 chiffres de précision en décimal. L'arrondi correct est 1.1. Or 0b1.0000110=1+1/32+1/64=1.046875≈1.0. Et tu ne peux pas distinguer si tu avais à l'entrée 1.046875, 1.05 ou même 0b1.00001100111 = 1+1/32+1/64+1/512+1/1024+1/2048=1.05029296875 avec tes 8 bits de précision.

Ok, il est vrai qu'en toute rigueur, j'aurais du dire quasi-garantie pour approx.
En pratique, ton exemple, par contre, marche sans aucun problème :

$ prec(8)
53
$ approx(1.05+0.05,2)
1.1E0

Et je rappelle que ce n'est pas limité à faire de l'arithmétique décimale, mais permet d'approximer n'importe quoi (sauf fonctions spéciales + trigonométriques).


Je cite la doc de may pour commencer à comprendre pourquoi ca marche :

int may_kernel_num_presimplify (int flag ) [Function]
When you parse strings, the float numbers may be evaluated to the current precision if flag is
set, or they may be stored as float-string, without evaluating them with the current precision:
we delay the evaluation to a later step where we know the needed precision. Set the current
value of this flag. Return the previous used flag. The default is 1, e.g. we evaluate the float
at parsing time.

Ok merci.

PpHd (./3) :
Cette arithmétique ne permet pas de représenter 97839.78 ou 8.76 de manière exacte : une approximation a été faite pour les représenter en base 2.

Marrant, pourquoi ne pas les représenter en tant qu'entiers, à une puissance de 10 près ? Ca resterait exact, non ? C'est peut-être ce qui est fait en interne en fait ?

Ben c'est ce que les TI et les autres calculatrices font, oui. Mais ça rend les calculs plus lents qu'en base 2.

Folco (./7) :
Marrant, pourquoi ne pas les représenter en tant qu'entiers, à une puissance de 10 près ? Ca resterait exact, non ? C'est peut-être ce qui est fait en interne en fait ?

1. Parce que l'arithmétique en puissance de 10 rame.
2. Parce que dès que tu balances la moindre fonction (ou même certaines opérations), de toute facon, tu as perdu ta représentation exacte.
Donc l'intérêt disparaît très vite.
3. Parce que approx est bien mieux (plus rapide et plus précis).