Autorisation : Membre
Nb de messages : 3767
Inscrit le : Lun 19 Oct 2009, 21:25
Posté le : Dim 03 Oct 2010, 19:11
Les informations que je trouve concernant les nombres de TI sont vagues...
J'ai donc décidé de partager des infos plus précises que j'ai déduites de mes diverses expériences sur ma 82statfr.
Vous pouvez aussi regarder ici et là
L'étude du système de la calculatrice en assembleur montre des choses, mais j'ai déjà effectué des tests sur la calculatric en TI-Basic.
EDIT 20/8/2013 :
des expériences supplémentaires de cet été m'ont montré que les calculs effectuent un arrondi du dernier chiffre de la mantisse. Mes expériences passées sont elle-même des cas particuliers.
STRUCTURE
Je m'attacherai aux nombres réels car les complexes semblent formés à base de réels pour les coefficients.
Tout d'abord, tout nombre est stocké dans la mémoire en notation scientifique :
-la mantisse = les chiffres significatifs (14 chiffres)
-le signe du nombre
-la valeur de la puissance de 10 et son signe (de -99 à 99) c'est-à-dire l'exposant
+1.234567 *10^ 12
PRECISION
Les nombres saisis directement sont tronqués.
EDIT 20/8/2013 :
J'avais affirmé que les calculs étaient toujours tronqués, mais je me trompais lourdement.
Lors de calculs, le dernier chiffre est arrondi d'après un 15ème chiffre calculé s'il y en a un.
EDIT 17/4/2014 Cf preuves dans mon prochain message.
Jusqu'à 10 chiffres de la mantisse peuvent être affichés à la fois. Le 10ème est un arrondi.
Quand la calculatrice pratique une condition logique (=,>,...) , elle semble utiliser 10 chiffres dont le dernier arrondi.
Quand elle pratique un affichage en mode fractionnaire, elle semble utiliser 12 chiffres dont le dernier arrondi.
9.999 999 999 999 9 E+99 si on le dépasse par d'autres décimales elles sont perdues.
1E100 et 10E99 provoquent des erreurs.
1E-100 provoque une erreur et (1E-99)/10 donne 0
X=a.bbb bbb bbb bbb b E-99 Si a=1, on peut mettre les décimales (b). Si a=0, on ne peut pas mettre les décimales.
---------------------- ti82statfr: 2008, inscrit: 2009, ti84pocketfr: noël2011, ti30xbmultiview: iut 2012-2014
Perfectionniste, manque tact. Pas le temps de tout publier depuis 2011. Répond toujours aux questions. (rédigé juin 2014)
Autorisation : Membre
Nb de messages : 3767
Inscrit le : Lun 19 Oct 2009, 21:25
Posté le : Jeu 17 Avr 2014, 22:08
Salut aujourd'hui j'avais un peu de temps à perdre, alors malgré le manque de popularité de mes articles d'expérience je présente quand-même ce que j'ai finalisé en trouvant quelques expériences plus fiables que par le passé.
Les calculs utilisent un chiffre supplémentaire en 15ème place en résultat avant d'arrondir à 14 chiffres. Je compte les places à partir du premier chiffre de la mantisse et c'est indépendant de l'exposant.
Quand vous testez, vérifiez si l'exposant change (retenue), car cela modifie les positions des chiffres dans la mantisses. On peut mal interpréter sinon.
### exemple
4*3333333.3333333
=13333333.333333_0
au lieu de
13333333.333333_2
L'exposant à changé à cause de la retenue. Donc on ne voit pas de 2 et cela porte à confusion.
###
Arrondi si le chiffre est supérieur ou égal à 6.
Cela suit la logique d'arrondir le résultat en fin de compte, mais comme on soustrait cela change la détection de la frontière.
2*8888888.8888888
=17777777.777778
au lieu de 17777777.777777_6
**** division
1/81
=.012345679012346
au lieu de
0.012345679012345_6...
2/3
=.666666666666667
au lieu de
0.666666666666666_6...
###########
Je me suis demandé si les conditions étaient réalisées avec une soustraction dont le résultat serait arrondi. Mais il semble plutôt que les deux membres sont arrondis à 10 chiffres puis comparés.
placer le curseur du graphique initialise X et Y sur les coordonnées avec 8 chiffres, et l'affichage est sur 8 caractères
Les calculs graphiques aussi (menu calcul)
TOLERANCE 1E-5 :
minimum et maximum, du menu Clacul (graphique)
TOLERANCE 1E-3 :
intégrale, du menu Clacul (graphique)
"Dans la plupart des fonctions, la précision est au minimum de cinq chiffres"
On ne peut pas juste parler de tolérance pour la fonction nbreDérivé/nDeriv puisque la valeur epsilon réglable est le pas d'abscisse, pas le pas de résultat. f'(~~(f(x+e)-f(x-e))/(2e)
Les indices des suites sont analysés lors des calculs pour vérifier que ce soient des entiers.
---------------------- ti82statfr: 2008, inscrit: 2009, ti84pocketfr: noël2011, ti30xbmultiview: iut 2012-2014
Perfectionniste, manque tact. Pas le temps de tout publier depuis 2011. Répond toujours aux questions. (rédigé juin 2014)
Autorisation : Membre
Nb de messages : 856
Inscrit le : Mer 18 Juil 2012, 18:44
Posté le : Dim 04 Mai 2014, 20:04
Intéressant.
Je m'étais déjà demandé comment cela fonctionnait (à l'occasion du ti concours au niveau du prgm sur les factorielles notamment), mais je n'ai pas pris le temps de poster mes observations.
Ainsi il y a toujours un arrondi qui est réalisé après le calcul au 14e chiffre.
Aussi, un truc que j'ai remarqué: si on saisis un nombre à plus de 14 chiffres, une troncature est faite au niveau de la mantisse, mais l'exposant demeure.
Ex: 11111 11111 11111 = 11111 11111 1111 * 10^1
et 11111 11111 11119 = 11111 11111 1111 * 10^1
Alors qu'avec un arrondi on aurait pu s'attendre à 11111 11111 1112 * 10^1
Cela ne marche pas si les premiers chiffres sont des "0", même s'il y a une virgule avant:
00000 00000 00001 = 1.0000 00000 0000
.00000 00000 00001 = 1.0000 00000 0000 * 10^-15
.01000 00000 00001 = 1.0000 00000 0001 * 10^-2
.10000 00000 00001 = 1.0000 00000 0000 * 10^-1
Par contre je n'arrive pas à comprendre la signification de tes colonnes concernant les conditions...
Autorisation : Membre
Nb de messages : 3767
Inscrit le : Lun 19 Oct 2009, 21:25
Posté le : Dim 04 Mai 2014, 21:11
La mise en page du tableau est pitoyable, pas étonnant que tu ais du mal à comprendre cette horreur que je n'avais pas relu online.
J'édite : évite les tabulations, utilise une balise code, change le nom des colonnes.
Je suis bien d'accord avec le fait qu'il y a troncature de la saisie directe. C'est bien une des seules choses dont j'ai toujours été sûr depuis mon premier post à propos des capacités.
Je ne pensais pas à une troncature textuelle, mais à une troncature de la mantisse des données. Tandis que l'exposant en écriture scientifique est indépendant de la mantisse.
0.0 11111 11111 11119*10^X = 1.1111 11111 1111_9 *10^(X-2)
tronqué à 1.1111 11111 1111 *10^(X-2)
###
Je viens à peine de m'apercevoir que l'éditeur de termes de listes et le tri des listes supportent toujours 14 chiffres. Aucune ambiguïté de comparaison et l'éditeur demeure en écriture Float à 14 chiffres.
Et alors je regarde la table de valeur.
Le champ d'édition de l'antécédent (mode ValeursDemande=IndependantAsk) est fixé à 14 chiffres.
L'autre mode (Auto) et les ordonnées (peu importe le mode d'ordonnée Auto/Ask) se limitent à l'espace de l'écran textuellement. Cela arrondi pour tenir dans l'espace si la valeur dépassait. Donc au plus 13 chiffres peuvent être consultés ou saisis par ce champ.
Il faut tenir compte de la taille du nom de l'équation, car c'est deux caractères pour les cartésiennes et polaires, trois pour les paramétriques, et quatre pour les suites ("u(n)").
Il semble que le champ d'édition et de consultation du bas de l'écran soit toujours en mode Float.
Dans tous les cas, si l'écriture en mode Normal ne convient pas, l'écriture se fait en mode Scientifique, comme le fait d'habitude l'écran principal avec 10 chiffres.
---------------------- ti82statfr: 2008, inscrit: 2009, ti84pocketfr: noël2011, ti30xbmultiview: iut 2012-2014
Perfectionniste, manque tact. Pas le temps de tout publier depuis 2011. Répond toujours aux questions. (rédigé juin 2014)
Autorisation : Membre
Nb de messages : 856
Inscrit le : Mer 18 Juil 2012, 18:44
Posté le : Lun 05 Mai 2014, 18:16
Il y a juste un décalage de 0.1 concernant la colonne des différences.
Par ex:
7777777777.7=7777777777.8_______7777777778______0_______________1
La différence est de 0.1, pas de 0.
Autorisation : Membre
Nb de messages : 856
Inscrit le : Mer 18 Juil 2012, 18:44
Posté le : Mer 14 Mai 2014, 15:08
Je viens de voir le début de l'article.
Citer : "Linkakro"
1E-100 provoque une erreur et (1E-99)/10 donne 0/quote]
Il faudrait préciser que 1E-100 renvoi une erreur syntaxe...
De même pour 1E100.
C'est parce que après le E la calto attend un nombre avec maximum 2 chiffres (une erreur syntaxe est levée également si un nombre ou un calcul suivent le E).
Par contre:
10^100 -> ERR:Capacité
10^-100 -> 0
[quote="Linka"]X=a.bbb bbb bbb bbb b E-99 Si a=1, on peut mettre les décimales (b). Si a=0, on ne peut pas mettre les décimales.[
C'est assez logique puisque les nombres sont codés certes avec une mantise de 14 chiffres (avec le premier forcément non null), mais l'exposant est délimité entre -99 et 99 donc quand on rentre 0.1E-99 ça revient (en mémoire) à 1E-100 donc ça passe à 0 (c'est la même chose pour 10E99 ça passe à 1E100 donc erreur mémoire).
D'ailleurs c'est bien dommage la perte de mémoire qu'il y a : chiffres décimaux codés sur des chiffres hexa pour la mantise, et exposant pouvant prendre 199 valeurs au lieu des 256 théoriquement stockables...
_le premier: Il sert à indiquer le type d'objet (0 pour nombre réel), et le signe (bit 7 à 1 si négatif, à 0 si positif).
$00 -> réel positif
$80 -> réel négatif
_Le second: il sert à l'exposant: on rajoute $80 à l'exposant pour avoir cet octet.
Par exemple, pour un exposant de -2:
$80 - 2 -> $7E
Pour un exposant de 3:
$80 + 3 -> $83
Donc on pourrait penser qu'on puisse aller de -$80 (-128) à $7F (127) mais la TI limite de -99 à 99...
_Les 7 suivants:
Les chiffres en décimal de la mantise
Donc on perd des données encore une fois: là où on peut stocker jusqu'à 16 chiffres différents on en permet que 10.
Donc si on veut stocker -3.1415926535897*10^6, les 9 octets correspondant seraient:
$80, $86, $31, $41, $59, $26, $53, $58, $97
Petite remarque:
Pour une mantise: 99999999999999, soit le maximum possible, on monopolise 14 chiffres héxa, soit 7 octets (+2 avec le signe et l'exposant).
Alors que 99999999999999 = $5AF3107A3FFF donc 12 chiffres, et encore il reste de la place pour le signer sur la mantise...
Donc je ne comprend pas trop pourquoi TI a choisi d'écrire sa mantise en décimal: est-ce vraiment plus pratique pour les calculs?
Encore la les limites de l'exposant sont compréhensibles, c'est pour faire "standard", mais là...
Autorisation : Membre
Nb de messages : 3767
Inscrit le : Lun 19 Oct 2009, 21:25
Posté le : Mer 14 Mai 2014, 18:56
Non la transformation de 1E-100 en 0 ne me parait pas logique car il faudrait déclencher un message d'erreur underflow.
La chose surprenante lorsqu'on ne connaît pas l'assembleur est le comportement des chiffres en underflow : la présence d'un chiffre zéro au début commande la mise à zéro du reste de la mantisse qui dépasse de la plage habituelle.
Oui TI a codé des nombres flottants en BCD (Binary Coded Decimal). Et oui la capacité de stockage est plus faible en BCD qu'en Binaire.
Le codage BCD est plus facile à gérer en relation avec l'écriture décimale et le processeur Z80 est conçu pour pouvoir effectuer des calculs arithmétiques en BCD directement. Comme ça l'utilisateur saisit en BCD, le calcul est BCD, le résultat BCD, et on n'a pas besoin de convertir en Binaire puis décimal.
Néanmoins la limitation de l'exposant à 99 est dommage puisque l'exposant est codé sur 1 octet qui donnerait +-128.
Mais lorsque j'ai commencé l'article il n'était pas encore question pour moi de consulter les ressources assembleur des systèmes TI, donc l'expérience du TI-Basic prévalait. De plus déduire par observation est un défi plus amusant que de lire la documentation assembleur.
Quelques SDK officiels de TI existent donc on peut se débrouiller seul en étudiant l'assembleur, mais les ressources communautaires sont bien plus claires et parfois même plus complètes.
---------------------- ti82statfr: 2008, inscrit: 2009, ti84pocketfr: noël2011, ti30xbmultiview: iut 2012-2014
Perfectionniste, manque tact. Pas le temps de tout publier depuis 2011. Répond toujours aux questions. (rédigé juin 2014)
Autorisation : Membre
Nb de messages : 856
Inscrit le : Mer 18 Juil 2012, 18:44
Posté le : Mer 14 Mai 2014, 20:04
Bah je pense que les 2 manières de faire (erreur underflow et transformation en 0) se valent, mais l'erreur underflow peut être un peu plus compliquée à comprendre de la part d'un utilisateur moyen que de se dire "mon résultat est très très proche de 0 puisque la calto affiche 0".
Citer
Le codage BCD est plus facile à gérer en relation avec l'écriture décimale et le processeur Z80 est conçu pour pouvoir effectuer des calculs arithmétiques en BCD directement. Comme ça l'utilisateur saisit en BCD, le calcul est BCD, le résultat BCD, et on n'a pas besoin de convertir en Binaire puis décimal.
Mais par exemple pour faire des additions/soustractions la gestion des dépassements de chiffres sont un peu plus complexes non?
Par ex: $99 + $99 = $132, donc il faut faire un autre algo que une simple addition gérée nativement.
Donc ça me surprend, puisque de toute façon la conversion héxa<->décimal n'est pas si complexe que ça...
Par contre la limite ne serait pas +-128 mais +-127 (sinon le 0 n'est pas compris).
Autorisation : Membre
Nb de messages : 3767
Inscrit le : Lun 19 Oct 2009, 21:25
Posté le : Mer 14 Mai 2014, 20:12
Oui je n'ai pas réfléchi, ce serait -128 à +127 en codage complément à 2.
Moi aussi je pense que le binaire aurait été plus puissant maintenant que j'y repense, mais nous ne connaissons pas toutes leurs raisons.
Des instructions du Z80 sont conçues pour les retenues, que ce soit en BCD ou en Binaire. Donc il n'y a aucune difficulté avec les retenues excepté la théorie des algorithmes.
---------------------- ti82statfr: 2008, inscrit: 2009, ti84pocketfr: noël2011, ti30xbmultiview: iut 2012-2014
Perfectionniste, manque tact. Pas le temps de tout publier depuis 2011. Répond toujours aux questions. (rédigé juin 2014)
Autorisation : Membre
Nb de messages : 856
Inscrit le : Mer 18 Juil 2012, 18:44
Posté le : Mer 14 Mai 2014, 20:32
Ce que je voulais dire avec les retenues c'est que du coup il faut le faire un chiffre par un, alors que sinon on aurait certainement pu faire 2 chiffres par 2.
Mais comme tu dis on ne connait pas toutes leurs raisons.
