Page 1 of 1

Bêta-test public mise à jour HP Prime 2.4.15354

Unread postPosted: 02 May 2025, 08:47
by critor
2234122342Aujourd'hui Moravia publie une nouvelle version dans le cadre du bêta test public de la mise à jour HP Prime 2.4.

Plus précisément nous passons de la version bêta 2.4.15342 compilée le 11 avril 2025 à la version 2.4.15354 compilée le 22 avril 2025.

Découvrons ce qui change.








1) Moteur de calcul

Go to top

La HP Prime dispose de 2 moteurs de calcul distincts :
  • un moteur de calcul numérique
  • un moteur de calcul littéral et formel accessible via la touche
    CAS
    et également appelable depuis partout ailleurs via des appels CAS.EVAL("...")
Le moteur de calcul numérique travaille sur des nombres au format BCD (Binary Coded Decimal) et ne s'occupait que de calcul décimal.

Hors touche
CAS
ou appels spécifiques, c'est donc le moteur numérique qui est utilisé, retournant des résultats approchés et non exacts. Sans manipulations spécifiques donc, la HP Prime haut de gamme se comportait moins bien que la plupart de la concurrence. Par possibilités croissantes :
  1. modèles disposant d'un moteur exact de type Q, disposant d'algorithmes spécifiques à la famille des nombres rationnels
    $mathjax$\pm\frac{a}{b}$mathjax$
  2. modèles disposant d'un moteur exact de type QPiRac, disposant d'algorithmes spécifiques aux deux familles de nombres suivantes :
    • QPi : multiples rationnels de π -
      $mathjax$\pm\frac{a\pi}{b}$mathjax$
      (pour les angles en radians notamment)
    • QRac : binômes de rationnels et/ou radicaux -
      $mathjax$\frac{\pm a\sqrt{b} \pm c\sqrt{d}}{f}$mathjax$
      (ce qui couvre un large ensemble allant des fractions du collège aux racines de polynômes du 2nd degré au lycée en passant par nombre de valeurs remarquables en trigonométrie)
  3. modèles disposant d'un moteur exact complet, travaillant sur des arbres de calcul et capable de retourner des résultats exacts pour toute saisie algébrique (NumWorks, TI-Nspire CX II-T)
22338Avant d'en arriver à cette décision, du temps où la HP Prime était encore pensée chez Hewlett Packard, des contournements avaient été mis en place.

Une fonction QPI() permettait à partir d'un résultat numérique approché de chercher une écriture exacte.

22310Nul besoin de saisir cette fonction à chaque calcul, la touche
a b/c
te permettait d'y faire appel pour changer la forme d'écriture du résultat sélectionné ou dernier résultat.

Et nul besoin non plus de taper cette touche à chaque appel, l'écran de configuration te permettait d'activer une option Intelligent Math l'appelant automatiquement pour chaque résultat.
22339Mais ce n'est qu'en apparence que tout ceci ressemblait à un moteur de calcul exact.

En interne le moteur ne travaillait que sur des nombres en écriture décimale. Et c'était des heuristiques qui tentaient de deviner une écriture exacte pertinente à afficher à la place de l'écriture décimale.

Il y avait bien des cas où, contrairement à la concurrence, cela se passait fort mal avec des résultats complètement faux.

Bref, une mauvaise solution qui ne faisait que masquer le problème tout en en introduisant un autre autrement plus grave !
Avec la mise à jour HP Prime 2.4, Moravia a commencé à s'attaquer enfin à ce lourd défaut. Le moteur numérique de la HP Prime est en cours d'amélioration en tant que moteur exact de type Q.

Un changement majeur ayant motivé ce bêta-test public, avec bien évidemment introduction de nouveaux problèmes que traite cette nouvelle version bêta.
223122231422313Dans le cas d'un format d'écriture utilisant des séparateurs de milliers, l'affichage naturel avait été cassé. C'est maintenant réparé !
2231822311La notation anglo saxonne des fractions négatives s'était mise à utiliser deux fois le signe moins.

C'est maintenant corrigé !
2230922310Vu ses résultats absolument désastreux, il était fort problématique que la calculatrice puisse être configurée pour fournir automatiquement sans avertissement des résultats QPI() possiblement complètement faux.

Moravia a bien compris le problème, c'est fini, la touche
a b/c
ne fait plus appel à cette fonction, et n'utilise plus que les résultats rationnels exacts et donc justes internes au nouveau moteur de calcul Q !
2232022317Problème qui existait déjà, lorsque l'historique de calcul contient une erreur en résultat, et que la calculatrice redémarre, son contenu était mal restauré.

L'erreur disparaissait ce qui décalait l'ensemble des éléments précédents (les saisies se retrouvant à droite comme des résultats, leurs résultats alors à gauche sur la ligne suivante comme des saisies, le tout agrémenté d'une saisie corrompue au tout début de l'historique).

C'est maintenant corrigé !




2) Programmation HPPPL

Go to top

Dans l'une de ses syntaxes, la fonction INPUT() du langage de programmation HPPPL permet de spécifier des boîtes de dialogue.
INPUT({vars}, "titre", {"étiquettes"}, {"aides"}, {réinitialisation}, {initiales}) avec :
  • {vars} (obligatoire) : la liste de couples variables à affecter + types de saisies aurisées
  • "titre" (optionnel) : le titre de la boîte de dialogue
  • {"étiquettes"} (optionnel) : les étiquettes à afficher à gauche de chaque champ de saisie
  • {"aide"} (optionnel) : les aides éventuelles pour chaque saisie
  • {réinitialisation} (optionnel) : les valeurs de réinitialisation si l'utilisateur souhaite effacer une saisie (touche
    Del
    avec le champ de saisie sélectionné)
  • {initiales} (optionnel) : les valeurs préremplies à l'ouverture de la boîte de dialogue, à défaut ce sont les valeurs courantes des variables qui seront utilisées
Quant aux types autorisés, rappelons les significations des différentes valeurs les identifiant :
  • -1 : tous
  • 0 : nombre réel
  • 1 : nombre entier
  • 2 : chaîne de caractères
  • 3 : nombre complexe
  • 4 : matrice
  • 5 : vecteur
  • 6 : liste
  • 8 : fonction
  • 9 : unité
  • 14 : expression CAS

Plusieurs bugs autour de cette fonction ont été traités.
223222232322324Il était impossible de valider une boîte de dialogue juste après avoir réinitialisé un champ via le touche
Del
.
INPUT({{A,[0]}},"La grande question",{"La réponse"},{},{0})

C'est corrigé !
22331Dans le cas d'une boîte de dialogue attendant une saisie de nombres réels (type 0), il était impossible de valider après avoir saisi un nombre non entier.
INPUT({{A,[0]}})

C'est corrigé !
2232722326Toujours niveaux identifiants de types autorisés, la fonction INPUT() acceptait des valeurs non entières et les interprétait étrangement :
  • Un type 0.2 par exemple était interprété en tant que chaîne de caractères (type 2).
  • Un type 0.1 par exemple était interprété en tant que nombre entier (type 1), tronquant alors les saisies décimales à l'unité.
22328C'est corrigé, les identifiants non entiers de types sont désormais refusés, générant une erreur !




3) Application Python

Go to top

22330L'application Python de la HP Prime présente le gros avantage de permettre de configurer les mémoires allouées, prises librement sur l'espace libre RAM :
  • le tas (heap), par défaut 1 Mio
  • la pile (stack), par défaut 40 Ko

2231522316Faut-il encore que les choix soient respectés, ce qui n'était pas le cas.
La HP Prime semblait systématiquement allouer le double du tas demandé, permettant donc par défaut d'affecter dans les 2 Mo de données.

C'est maintenant corrigé !
2233222333En espagnol, le titre de la console Python était tronqué avec un caractère spécial.

C'est maintenant corrigé !




4) Application Géométrie

Go to top

223362233722335Dans le cas de tracé d'un champ de direction, la couleur utilisée pouvait varier.

C'est maintenant corrigé !





Mieux vaut tard que jamais, nous ne pouvons que saluer les efforts de Moravia pour corriger l'inadéquation de la HP Prime avec les besoin de l'enseignement secondaire, même si cela a le tort d'arriver 20 ans après la concurrence, et d'être très loin de l'égaler.

Appeler le moteur de calcul formel CAS pour les résultats numériques, comme le langage HPPPL le permet, aurait donné un moteur de calcul exact complet comme sur NumWorks ou TI-Nspire CX II-T, et non comme ici un moteur de calcul exact Q inférieur au QPiRac proposé par tout le reste de la concurrence.

Nous ne comprenons pas que cela n'ait pas été fait plus tôt alors qu'il y avait tout ce qu'il fallait sous la main, ni qu'on se donne la peine maintenant de coder un moteur de calcul exact alternatif très inférieur pour cela. Y a-t-il une raison d'éviter à tous prix de dépendre davantage du moteur CAS ?...




Téléchargements :