Le forum de XCAS

Bonjour,
Un comportement un peu surprenant de floor/evalf:
evalf(8^(1/3)) renvoie 2.0
alors que
floor(evalf(8^(1/3)))
et
floor(8^(1/3))
donnent 1
Je suis sous 0.9.4 linux ( 0.9.5 fait pareil).
Sous windows 0.9.4 c'est different, c-a-d. floor(8^(1/3)) = floor(evalf( 8^(1/3))) =2.

Le comportement sous windows est plus intuitif et donc souhaitable, mais est-il correct?
Parce que peut-etre en "realite" de floats la valeur de evalf( 8^(1/3)) est < 2 et c'est seulement l'affichage qui cache la verite?
(ici Digits=12; si on passe a Digits=15 ca devient coherent, toutes les expressions donnent 2.000.... ou 2).

Serait-il envisageable de traiter les racines cubiques d'une maniere exacte? Comme quoi 8^(1/3) vaudrait 2 tout court.

On peut comprendre pourquoi en faisant:
evalf(8^(1/3))-2.0
le resultat est legerement negatif (en precision par defaut a 12 chiffres, c'est-a-dire en fait affichage de l'arrondi a 12 chiffres et calcul avec des flottants hardware double precision et arrondi a 0 par xcas des 8 derniers bits de la mantisse sur les 53 bits de mantisse hardware).
On pourrait bien sur rajouter des cas particuliers pour reconnaitre des racines cubiques ou autres avant d'appeler l'evaluation numerique dans floor, mais d'une part il faudrait decider ou on s'arrete, et d'autre part cela aurait un cout. Il me parait plus simple de laisser le choix a l'utilisateur de simplifier ou pas son expression avant de la donner a floor (ici simplify(8^(1/3) renvoie bien 2 donc floor applique dessus renvoie 2). Sachant qu'a un moment donne l'evaluation numerique sera appelee (sauf argument rationnel), et que la fonction etant discontinue en les entiers on a inevitablement un risque d'erreur d'arrondi qui se traduira par une difference de 1 ici (et il me semble qu'il faut sensibiliser les candidats au capes a ce genre de problemes).

Merci pour ces explications.
En ce qui concerne la sensibilisation aux erreurs d'arrondi, je suis tout a fait d'accord! (d'ailleurs ça vient d'un exo L2 qui devrait mettre en valeur ces erreurs). D'accord aussi pour la simplification facultative et independante de la "numerisation" (qui n'a pas forcement pour but de traiter des cas particuliers). En y reflechissant, c'est une bonne chose!

Ce qui est peut-etre surprenant, c'est que evalf(..) n'est pas tout a fait d'accord avec floor(evalf(...)).
On va comprendre que c'est normal, car avec Digits=12 on calcule avec le hardware et on n'affiche pas que 12 chiffres.
OK, mais pourquoi donc cacher les derniers chiffres et ceci par defaut ?
Je trouve normal de voir la "vraie" valeur d'une variable ("vraie" = celle qui passe pour les calculs).
Et si on veut tronquer, on peut toujours le faire explicitement. N'est-ce bien le cas pour Digits>14?

Par ailleurs, l'affichage tronque par Digits (<14) est "globale" et une affectation de Digits change aussi les resultats afiches avant:
Digits:=5; evalf(pi)
Digits:=10; evalf(pi)
Je trouve cela un peu surprenant (par rapport au comportement normal de la feuille de calcul) et pas tres facile a manier. J'irais meme a suggerer de ne pas tronquer l'affichage globalement avec Digits mais seulement localement avec une commande explicite (evalf ou encore une commande speciale pour l'affichage).

Independament, dans la fenetre de config on pourrait mettre pour l'option Digits une case "processeur" ou ""Multiprecision" alors avec une valeur >15. C'est enfin comme ca que ca se passe maintenant (un peu en "cachette").
Oui, je sais, je sais, avec mes idees, au lieu d'encombrer ce forum je devrais plutot ecrire un petit logiciel "xcas pour les nuls". Eh bien, qui sait...

je suis d'accord, il y a un comportement piegeux avec Digits < 14 qui n'a pas la meme signification que Digits>=14. En fait, le defaut devrait peut-etre etre de 13 decimales et pas 12, puisqu'on a 45 bits de mantisse (donc 3.5e13). Par contre, je pense que l'usage est de pouvoir afficher moins de decimales (en gardant plus de decimales pour le calcul) comme sur les calculatrices et changer ca serait non intuitif. Donc pour resumer les ambiguites:
Digits<=13 implique hardware float tronque pour tout flottant cree (j'utilise en interne les 8 bits de poids faible de la mantisse pour le typage des objets "gen" qui sont codes sur 64 bits) et Digits ne gere que l'affichage mais de tous les hardware floats.
On peut utiliser round pour arrondir (et donc modifier un hardware float), par exemple round(pi,3)
Digits>=14 implique utilisation de MPFR (flottants multi-precisions) pour tout nouveau flottant cree. L'affichage depend de la precision de l'objet (autrement dit si on change Digits on ne change pas l'affichage d'un objet existant, y compris s'il est evalue).
Et evalf(objet,precision) permet aussi de creer des flottants multi-precisions a partir d'objets exacts numeriques.

Merci pour ces précisions ! Ca m’eclaircit des choses (et enleve par ailleurs une petite ambiguite dans l'aide en ligne pour "Digits" ou on parle de valeur "inferieur" ou "superieur" a 14, j'avais des doutes).

Oui, l'affichage tronque est sans doutes tres present, surtout pour les calculettes. Mathematica tronque a 5 chiffres par defaut (l'avantage dans ce cas c'est l'evidence d'une tel manip, mais je ne connais pas vraiment plus de details).
Pour justifier mon poste, mon intuition venait plutot de Maple ; je joins un petit exemple ou on commence avec Digits=10 par defaut.
Bref il parait qu'on calcule avec ce qu'on voit:

Et il parait que c'est a peu pres pareil en Xcas multiprecision (c-a-d la difference entre l'affichage et la valeur "reelle" ne se voit pas si facilement avec Digits>=14). Exemple :


13 chiffres par defaut, comme vous proposez, rapprocherait l'affichage et la valeur "reelle" et uniformiserait le comportement.
Est-ce que ca veut dire que l'on verra tous les chiffres (il y en a 14 a la limite)? Sinon, pourquoi cacher le dernier chiffre (ou pourquoi montrer tous les chiffres serait non-intuitif? pourquoi faire une difference dans le comportement/affichage entre Digits<14 et MPFR?)

A.
PS. En fait, c'est une formidable difference entre un logiciel commercial et p.ex. xcas. Maple/Mathematica ne sont peut-etre pas mal, mais nous cachent a peu pres tous les details. En realite on ne peut pas les bien comprendre au dela d'un certain usage habituel. Xcas a ses conventions, on peut les aimer bien ou pas trop -- mais enfin tout est transparent si on veut ! Et en plus on peut venir embeter l'auteur et encore obtenir des explications...
Merci donc pour un travail enorme que vous fournissez. Et je vais essayer de produire moins de texte...

La difference avec Maple, c'est que Maple n'utilise pas par defaut les hardware float (on peut l'obliger avec l'instruction evalhf), mais travaille avec des flottants multiprecisions en base 10 quel que soit le nombre de digits (sauf pour certaines instructions ou des libraires exterieures sont appelees, comme par exemple LAPACK avec factor(polynome,complex)). Ce qui explique certaines lenteurs dans des calculs numeriques. Xcas pourrait utiliser MPFR tout le temps mais ce serait au prix de pertes de performance importantes (temps des operations arithmetiques faites en soft au lieu d'etre faites par le CPU mais aussi allocation memoire dynamique des flottants multiprecision alors que les flottants hardware ne sont pas alloues dynamiquement).
Xcas est plus proche des langages traditionnels pour les flottants (calcul avec 53 bits et affichage variable, cf. par exemple la doc de printf ou de cout en C/C++) sauf bien sur en multiprecision. Et pour le nombre de chiffres affichables, on peut passer a 13, mais pas a 14, car le dernier chiffre serait faux en raison de la perte des 8 derniers bits de la mantisse des hardware float (2^45=3.5e13). Evidemment on peut aussi compiler xcas avec des "gen" un peu plus grands (compile flag -DDOUBLEVAL: 96 bits au lieu de 64) pour eviter de perdre ces 8 bits de mantisse des double et avoir quasiment 16 chiffres significatifs, mais cela aurait un impact sur la taille memoire des donnees de xcas et donc sur les performances.