Précision des calculs sur TI et Casio

[Coudray]

Je m’intéresse à la précision de nos calculatrices.

Je vois la précision documentée par critor dans le comparatif, par la méthode 1+x-1, et j’ai vérifié que j’ai bien ces résultats sur mes calculatrices. Par exemple, sur ma TI 36x pro Mathprint, je constate que le résultat est 0 pour [x| < 3E-10, ce qui semble bien correspondre à une précision sur 32 bits. Pourtant, on peut constater que d’autres calculs se font avec une précision sur 13 chiffres, pi et e sont d’ailleurs donnés sur 13 chiffres.

On peut constater cette précision en calculant par exemple (en Radians) :
Tan(355/226 + x) - Tan(355/226)

La résolution est de 1E-12 en x (pour une variation de 56 en y !) ce qui indique plutôt un calcul sur 40 bits et non 32.

Qu’est-ce donc que ce seuil de 3E-10 pour le 1er calcul ?
Je crois comprendre que c’est lié au traitement QPiRac : ça correspond au seuil qui permet d’affecter un nombre QPiRac : si |x| < seuil, alors la calculatrice conserve l’entier “1” dans notre calcul, un arrondi est donc effectué (le seuil semble différent si PI est présent dans le nombre)

Il semble que nos calculatrices travaillent donc avec une certaine précision pour les calculs (sur n bits) et d’autre part avec un seuil concernant le moteur QPiRac qui peut effectuer un arrondi.

La même manip sur mes autres calculatrices donne ces résultats, avec dans l’ordre :
"Seuil QPiRac" / Précision des calculs (nombre de bits)

TI 36x Pro : 3E-10 / 1E-12 (40 bits - et non 32)
TI 30x Pro : 9,5E-12 / 8E-13 (40 bits - et non 37)
Casio Graph 90+E: 1E-12 / 1E-14 (48 bits? - et non 40)
Casio Graph Light : 1E-18 / 1E-22 (76 bits? - et non 60)

Avec une calculatrice graphique, si on trace 1+x-1, on voit parfaitement le “plat” en 0,0, de la largeur du seuil de part et d’autre.
Par exemple sur la Casio Graph Light, avec une fenêtre graphique xmin = -9.5E-18, xmax = +9.5E-18, ymin = -3.1E-18, ymax = +3.1E-18



Qu’en pensez-vous? C’est peut-être quelque chose de connu, mais je n’ai vu ça nulle part...

[critor]

Bonjour.


Merci pour ce partage fort intéressant.
Il se pourrait que la calculatrice décide par elle même d'arrondir, dans certains cas.

Reste après à savoir si on conserve le meilleur ou le pire des cas.

Par rapport au graphe, pour voir, je viens de tenter sur Graph Light en désactivant le moteur QPiRac dans les paramètres, mais ça semble ne rien changer à la taille de l'intervalle d'annulation autour de zéro.

[critor]

Je confirme pouvoir aller jusqu'à 2^-73 sur Graph Light avec la tangente dans le voisinage de Pi/2.





Je conserve cette fonction fort intéressante en mémoire, merci beaucoup pour ce retour fort précieux, peut-être que je mettrai à jour toute la banque de données avec quand j'aurai le temps.

[Coudray]

Par rapport au graphe, pour voir, je viens de tenter sur Graph Light en désactivant le moteur QPiRac dans les paramètres, mais ça semble ne rien changer à la taille de l'intervalle d'annulation autour de zéro.

Bonjour,
L'option Smaths/Rmaths je suppose ?
Donc, s’il n’y a pas moyen de le débrayer, ce plateau pourrait être intégré “en dur” au moteur de calcul ? Du genre : Si tout résultat de calcul en valeur absolue est inférieur au seuil, on l’annule. (ou peut-être même, en binaire, à partir d’un certain rang, si tous les bits plus significatifs sont à 0, on annule les bits moins significatifs, par exemple à partir du ~32e bit sur la TI36x, ou à partir du ~60e bit sur les casio CW ?)
De cette façon, les calculs pour trouver un QPiRac, que j’image être une plus ou moins grande séquence de tests de combinaisons différentes, seraient juste des tests d’égalité et non des tests d’inégalité par rapport à un seuil ?

Pour déterminer le nombre de bits utilisés pour la mantisse, je pense qu’il faut un peu tenir compte de la façon dont elle est codée.
J’ai refait des tests sur le calcul de 1+dx-1, avec d’autres valeurs que “1”.
Je constate que pour toutes les valeurs de 1 à 9,99.. les seuils sont les mêmes (3E-10 et 1E-12 sur la TI36x ). Si on passe à 10, les seuils sont multipliés par 10. Même chose sur la TI30x et les 2 Casio. Donc la plage à prendre en compte pour le calcul du nombre de bits, doit être non pas par rapport à 1, mais à 10, ce qui ajoute log2(10)= 3,3 bits. (sur TI36x, 10/1E-12=1E13 soit 43,2 bits, sur Casio CW: 10/10E-22 = 76,4 bits)
(Mais est-on sûrs que le codage se fait en binaire ?, ça pourrait être en BCD codé binaire, ce qui demanderait plutôt 4x13=52 bits sur TI)

Le plus simple serait de faire le test avec 0,99 au lieu de 1. Le seuil et la résolution sont alors divisés par 10 et représentent directement la précision maximum en nombre de chiffres significatifs (ou de bits calculés)

Par exemple sur TI36x : résolution 1E-13 (43,2 bits), seuils du “plateau” : 3E-11 (35b).

Au final, on a quoi comme précision globale pour un calcul simple ? selon les opérandes, on a une précision variable : sur TI36x de 1E-13 à 3E-10, donc en gros de 10 à 13 chiffres significatifs. Sur Casio CW, de 18 à 23 chiffres significatifs.

[Opoint]

L'effet au voisinage de π/2 est probablement lié aux identités trigonométriques employées par les calculatrices. Comme 355/226 vaut à peine plus que π/2, la calculette utilise probablement tan θ = cotan (π/2 - θ), les calculs trigonométriques porterons alors sur π/2 - (355/226 + 10^-22) soit environ -1,33×10^-7 - 10^-22. Et de 10^-7 à 10^-22 il y a seulement 15 décimales d'écart. Il faut encore utiliser le fait que cos est paire et sin impaire pour se ramener dans, par exemple, [0,π/2], mais toutes ces propriétés sont exploitées par les implémentations des fonctions trigonométriques. Et ceci bien avant que QPiRac ou le calcul formel n'apparaisse sur les calculatrices. L'intervalle [0,π/2] est ainsi mentionné dans la description de CORDIC sur wikipédia https://fr.wikipedia.org/wiki/CORDIC. Je suppose que les calculettes équipées d'un microcontrôleur avec multiplicateur matériel exploitent plutôt des développements limités. Peut être peut-on remonter des erreurs observées autour de π/2 et π/4 à l'implémentation employée / l'intervalle utilisé ? Pour en revenir au calcul de tan, c'est la précision avec laquelle π ou π/2 est embarqué dans la calculette qui va être critique pour des calculs comme π/2 -θ. Les bonnes implémentations embarquent bien plus de décimales que la précision machine et exploitent ces décimales à bon escient.

Edit: La trouvaille de Coudray marche même avec10^-22 + 355/226, donc ce n'est pas une application au niveau de l'expression de ce qui était fait avant au niveau des implémentation numériques. À moins d'une multiplication par 2/π terme à terme, c'est bien mystérieux…
PS: pour le fun, le 2/pi employé par l'implémentation de la glibc pour les très grands arguments est visible là, dans le tableau toverp : https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/ieee754/dbl-64/branred.h

[Coudray]

Je fais le bilan de ce que j'ai compris jusque là.
Sur mes calculatrices TI et Casio qui ont un traitement QPiRac (assimilation à une expression exacte avec fraction/Pi/Racine), le moteur de calcul fait un arrondi ou plutôt une annulation d'un résultat suffisamment petit (quand dans un résultat de calcul, la mantisse est suffisamment petite).

C'est mis en évidence par le résultat d'un calcul comme celui que fait Critor pour le champ précision dans la base des calculatrices (1+x-1).

Casio Graph 90+ E

En affichant la fonction 1+x-1, on voit l'annulation du résultat pour |x| plus petit que 1E-12.
C’est la plus grande erreur relative que peut faire la calculatrice pour un calcul élémentaire (plus grande erreur due à l’annulation en 0, divisé par la plus petite valeur, 1, de la mantisse de l’opérande), ici 1E-12 :



La même chose avec un entier plus petit que 1, les seuils sont divisés par 10 (plateau à 1E-13), et si on sort du plateau, on voit les valeurs des marches d’escalier de la rampe et donc la résolution maximum de la calculatrice. L’erreur relative est minimum (mantisse de l’opérande maximum et erreur minimum), ici 1E-15 :



La précision de la CG90 est donc de 12 à 15 chiffres (40 à 50 bits)

TI-36X Pro



Le plateau est à 3E-11, la résolution 1E-13.
(Le plateau est 30 fois plus grand que sur la TI-30x Pro MathPrint !)
La précision est donc de 10 à 13 chiffres (32 à 43 bits)

TI-30X Pro MathPrint



Le plateau est à 1E-12, la résolution 1E-13.
La précision est donc de 11 à 13 chiffres (37 à 43 bits)


Casio Graph Light

f(x)=1+x-1, plateau à 1E-18



(avec 0,99, la résolution est à 1E-23)
La précision est de 18 à 23 chiffres (60 à 76 bits)


Conclusion :

Le calcul de critor dans la bdd : 1+x-1 est très bien car il permet d’avoir la précision assurée (le pire cas pour un calcul élémentaire).
Mais il ne donne pas la précision maximum/nominale (qui correspond au nombre de chiffres donnés pour les constantes pi et e, et indiquée dans le manuel - pour ces 4 calculatrices)
Cette précision nominale pourrait être ajoutée en s’assurant de sortir du plateau, comme j’ai fait là, ou comme par exemple avec le calcul de la tangente près de pi/2 avec tan(355/226+x)

[Opoint]

Je serai surpris que e ne face pas aussi l'objet d'un stockage avec des chiffres en plus. Historiquement Intel c'est bien vautré avec π à ce sujet, avec un calcul imprécis de sin(π) :
https://randomascii.wordpress.com/2014/10/09/intel-underestimates-error-bounds-by-1-3-quintillion/

[Coudray]

J'ai trouvé des anomalies à l'examen de la précision des calculs de la Casio Graph 90+E. Détails :

La "signature trigo" est f(9 degrés) (pour la CG90 : 8​.​9​9​9​9​9​9​9​9​7​5​9​4​6​8, ou -2,40532E-9, ligne mauve en pointillés) et caractérise le moteur de calcul. Intuitivement, je considérais ça un peu comme un indicateur de la précision de la calculatrice. Mais si on trace la même fonction autour de 9, on constate que l'erreur est aléatoire et comprise entre +/- 4E-9, et peut être à 0.



Et donc, c'est faux, ce n'est pas un indicateur de la précision, et pour certaines calculatrices, comme ça tombe au hasard, ça peut être beaucoup plus petit que la précision sur ce calcul.

Si on agrandit, on voit un motif apparaître, des rampes allant de 4E-9 à -4E-9.
(offset x=9)



Mais je suis tombé sur des anomalies où l'erreur est bien plus grande, par exemple ici en 9,000 034 (offset x=9) :



Si on dézoome, on voit des erreurs allant jusqu'à +/- 6.5E-8, (soit 15 fois plus)
(la ligne mauve est toujours la signature trigo)



On en trouve un peu partout, comme ici en 9,000452429, mais aussi en 9,0014285 ou 9,0028227 ou 9,0044258 etc.,



En échelle logarithmique, en traçant log( |f(x)-x| +1E-15), on a directement le nombre de chiffres exacts. Pour l'anomalie, on tombe de 8,6 à 7 chiffres.
(offset en x de 9,000034. l'anomalie a une largeur de 1,28E-7. La précision nominale de la CG50 étant de 15 chiffres, j'ajoute 1E-15 pour éviter log(0), mais c'est facultatif)



Donc on a une dégradation notable de la précision, de plus d'un chiffre, dans certains cas. Je pense que c'est dû à l'arrondi/troncature QPiRac que j'ai mis en évidence plus haut. Cet arrondi semble être appliqué à des calculs intermédiaires, et est amplifié par les fonctions trigo avec les petits angles. Je n'ai pas réussi à déterminer à quelle étape du calcul c'est provoqué, et pour quelles valeurs QPiRac.

Je n'ai rien vu d'équivalent sur la graph light. Mais la précision est bien supérieure, 23 chiffres, ça risque d'être plus difficile à mettre en évidence. Sur mes TI 36x et 30x Pro, non graphiques, c'est encore plus difficile.

Sur la nouvelle Math+, il est probable qu'on ait la même chose que sur la CG90+, si c'est le même moteur de calcul. Quelqu'un veut essayer ?