Forum TI-Planet.org

Dans une actualité précédente nous te faisions part du changelog officiel de la nouvelle version TI-Nspire 3.6, mentionnant entre autres des améliorations du moteur CAS:

Texas Instruments wrote:La fonction de calcul du logiciel TI-Nspire™ CAS a été mise à jour afin d'améliorer la fonctionnalité de calcul et de répondre aux commentaires des utilisateurs concernant les algorithmes mathématiques. La fonctionnalité améliorée respecte les restrictions sur le domaine des variables de solution et apporte des améliorations à la résolution d'équations ou de systèmes d'équations, plus particulièrement lorsqu'une équation comporte des exposants rationnels.

Cette phrase bien que fort enthousiaste, restait quand même assez générale et vague. Tentons de voir ce qu'il en est vraiment avec des bugs que nous avons signalés dépuis la rentrée 2012.



Toujours aucune gestion des fonctions trigonométriques inverses en k*Pi/5, k*Pi/8, k*Pi/10 et k*Pi/12. Ce manque de fonctionnalités symétriques crée des incohérences par rapport au fonctionnement avec d'autres valeurs remarquables ou avec un paramètre formel. Le problème est présent depuis de la toute première TI-92 1.0.

Il est toujours possible d'exploser la mémoire avec certains calculs, problème introduit dans la version TI-Nspire 2.0.

Toujours des difficultés pour simplifier certains quotients de radicaux, nécessitant alors plusieurs évaluations. Or, le système TI-Nspire n'est pas prévu pour simplifier par étape, et mélanger expressions partiellement et totalement simplifiées crée nombre de problèmes pour les calculs ou fonctions qui elles s'attendent à des résultats simplifiés. Ci-dessous par exemple, le dernier résultat devrait être nul. Le problème est présent depuis la version TI-Nspire 3.2.




Je ne sais pas où se situent les améliorations officielles du moteur de calcul formel CAS, mais visiblement rien n'a été fait pour ces calculs pourtant rencontrables dans le contexte de problèmes dès l'enseignement secondaire.

Faut-il toutefois jeter la pierre à TI ? Certes non. Pour son système TI-Nspire CAS, TI a fait le choix de faire coexister et collaborer plusieurs moteurs de calculs:

• un moteur de calcul formel
• un moteur de calcul numérique exact
• un moteur de calcul numérique approché

Il se trouve que les deux moteurs de calcul formel et exact bien qu'obéissant aux mêmes règles de calculs, n'effectuent pas les simplifications de la même façon. Là où le moteur formel gère des cas généraux, le moteur numérique exact gère des cas particuliers. Aussi, ces deux moteurs peuvent même entrer en conflit dans leurs simplifications, ce qui peut amener à des simplifications inachevées ou à des boucles infinies explosant la mémoire (chacun défaisant à son tour le travail de l'autre) comme vu ci-dessus. Toute la difficulté est donc dans le choix de l'appel au bon moteur à chaque étape de la simplification en fonction de la forme de l'expression.
Faire collaborer des moteurs de calcul formel et exact est tout simplement un problème difficile. Vous remarquerez d'ailleurs ci-dessus qu'il y a toujours des paramètres numériques. Si l'on remplace tous les nombres par des lettres, les problèmes disparaissent.

Mentionnons à ce sujet un fait intéressant: le constructeur HP avec sa HP-Prime a fait le choix différent de scinder sess moteurs de calcul mais à un autre niveau. Deux touches différentes permettent d'accéder:

• à un contexte utilisant des moteurs de calcul formel et numérique exact
• à un contexte utilisant un moteur de calcul numérique approché

Du point de vue du mathématicien ou du programmeur, c'est certes un choix fort logique et justifié. Du point de vue de l'utilisateur qui ignore le fonctionnement qu'il y a derrière, je ne pense pas que mettre deux boutons était le meilleur choix.

Dans le même style, une solution 'facile' aux problèmes de TI serait la séparation des moteurs de calcul formel et exact.
Mais le choix de TI me semble tout simplement, malgré sa bien plus grande complexité, beaucoup plus adapté à l'utilisateur final.


Par contre en sachant pertinemment que ces bugs n'ont pas été corrigés, il n'est absolument pas acceptable que Texas Instruments en plus de nous inciter à passer à la version 3.6, y ait inclus nombre de protections destinées à nous empêcher de revenir ensuite aux anciennes versions dont le moteur CAS fonctionnait mieux.
Le budget et le temps dépensés dans ces sécurités stériles, auraient clairement pu être réinvestis dans des améliorations du moteur CAS, de façon plus constructive et dans l'intérêt de tous.

Pourquoi ne suis-je pas surpris que l'OS 3.6 calcule toujours mal, alors qu'on a dûment reporté les bugs ? Ah oui, parce qu'ils ont passé du temps et de l'argent à faire des protections, c'est vrai...
Question de choix de priorité... tenter de protéger un business model pourri plutôt que de faire des choses bien.

moi je dis vive l'os 3.1, c'est une valeur sure.

Oui cet OS 3.6 n'apporte rien de vraiment emballant... Merci TI...

Bonjour,

Juste un mot sur la comparaison que vous faites entre les moteurs TI et HP, qui me parait inexacte alors que le reste de vos articles sont tres interessants et tres bien documentes. Je ne sais evidemment pas comment le moteur de la nspire est fait exactement, mais il me semble que la TI nspire CAS et l'utilisation de la HP en mode CAS sont tout a fait comparables. Au sens ou le moteur CAS de la HP fait aussi du calcul numerique (en mode exact ou approche), et pas simplement du calcul formel. Il faut d'ailleurs faire attention, calculer avec des racines imbriquees de nombres, c'est du calcul numerique exact, partie integrante du calcul formel, a ne pas confondre avec du calcul approche, seule chose qu'on peut faire dans le Home de la HP, mais qu'on peut aussi faire depuis le CAS de la HP.
Je suis curieux de savoir si l'arrivee de la HP Prime a cree un peu d'emulation sur le front du calcul formel, apparamment non (en tout cas on peut s'etonner de ne pas avoir plus de precisions sur les ameliorations de la 3.6). Pas tres etonnant vu le marche cible.
Sur le point des lignes trigonometrique directes et reciproques particulieres, j'ai trouve une solution simple pour la HP qui se trouve dans le code source de giac et qu'il ne serait pas difficile a TI d'implementer. Pour les racines imbriquees, c'est plus delicat, sur la HP vous aurez en tout cas la reconnaissance du 0 (dans les limites des capacites memoire si les expressions sont tres compliquees)

Merci beaucoup pour votre précision.

Je vais tenter de creuser la chose, et de rendre le passage en question plus exact.

Bonjour,

parisse wrote:Juste un mot sur la comparaison que vous faites entre les moteurs TI et HP, qui me parait inexacte alors que le reste de vos articles sont tres interessants et tres bien documentes.

C'est fort touchant, surtout de votre part, et je vous en remercie.
Je n'ai pour ma part pas la prétention de faire bien plus que de la 'vulgarisation', puisque cherchant à rendre l'information accessible au moins à un niveau lycée, mais certes en évitant de perdre pour autant en exactitude.

Je viens de modifier la fin du passage, de la façon suivante.
Je pense que cela convient mieux.

Sinon, n'hésitez pas à me reprendre à nouveau.

Il se trouve que les deux moteurs de calcul formel et exact bien qu'obéissant aux mêmes règles de calculs, n'effectuent pas les simplifications de la même façon. Là où le moteur formel gère des cas généraux, le moteur numérique exact gère des cas particuliers. Aussi, ces deux moteurs peuvent même entrer en conflit dans leurs simplifications, ce qui peut amener à des simplifications inachevées ou à des boucles infinies explosant la mémoire (chacun défaisant à son tour le travail de l'autre) comme vu ci-dessus. Toute la difficulté est donc dans le choix de l'appel au bon moteur à chaque étape de la simplification en fonction de la forme de l'expression.
Faire collaborer des moteurs de calcul formel et exact est tout simplement un problème difficile. Vous remarquerez d'ailleurs ci-dessus qu'il y a toujours des paramètres numériques. Si l'on remplace tous les nombres par des lettres, les problèmes disparaissent.

Mentionnons à ce sujet un fait intéressant: le constructeur HP avec sa HP-Prime a fait le choix différent de scinder sess moteurs de calcul mais à un autre niveau. Deux touches différentes permettent d'accéder:

• à un contexte utilisant des moteurs de calcul formel et numérique exact
• à un contexte utilisant un moteur de calcul numérique approché

Du point de vue du mathématicien ou du programmeur, c'est certes un choix fort logique et justifié. Du point de vue de l'utilisateur qui ignore le fonctionnement qu'il y a derrière, je ne pense pas que mettre deux boutons était le meilleur choix.

Dans le même style, une solution 'facile' aux problèmes de TI serait la séparation des moteurs de calcul formel et exact.
Mais le choix de TI me semble tout simplement, malgré sa bien plus grande complexité, beaucoup plus adapté à l'utilisateur final.

Bien cordialement.

Bonjour,

Difficile de deviner pourquoi on a des resultats non simplifies ou des ressources exhaustion sur la nspire. Il est possible que certains algorithmes ne soient pas optimises (je passe beaucoup de temps a ca pour giac), les calculs necessitent tres rapidement beaucoup de ressources, du coup ca donnerait une erreur dans certains cas, dans d'autres peut-etre qu'un timeout provoque un retour de resultat non simplifie. Il est aussi fort possible qu'il y ait un bug dans une partie du code source ecrit il y a longtemps (a l'epoque de Stoutmeyer et de Derive) que plus personne n'est capable de maintenir chez TI (ou alors cela necessiterait beaucoup de temps et de ressources sans etre rentable pour TI). La maintenance de code sur de longues periodes peut deja etre problematique sur du code open-source, alors sur du code closed source...
Sinon, le moteur de calcul formel de la HP est tout aussi capable de faire du calcul numerique approche. Et c'est ce qui se passe quand vous entrez une valeur approchee dans une expression dans le CAS, ce n'est pas le moteur numerique de Home qui est appele. En fait les 2 moteurs n'utilisent meme pas les meme formats de flottants (c'est du BCD dans Home et ce sont des "doubles" dans le CAS). Un peu comme s'il y avait 2 calculatrices en 1, chacun peut utiliser celle qui l'interesse. On continue a ameliorer le code pour faciliter le passage de l'une a l'autre, c'est sur qu'il y a des difficultes avec par exemple le systeme des variables preaffectees de Home si elles sont utilisees dans une instruction du CAS qui attend une variable symbolique libre. A l'heure actuelle, il y a encore quelques rugosites, mais je ne doute pas que ces defauts de jeunesse seront vite oublies et j'espere qu'on aura aussi bientot une bonne documentation du CAS sur la Prime (Renee a un document en cours de finition d'ailleurs, qu'on peut trouver sur le forum de Xcas).