Forum TI-Planet.org

Symb

Plot

Num

⌂

CAS

Plot

Passons maintenant à la remarquable application Graphique 3D de la HP Prime.

Par exemple prenons la fonction d'expression .
À partir de sa vue graphique (touche

Plot

), il t'était possible de zoomer ou dézoomer à l'aide des touches

+

ou

-

.

Sauf que les nouvelles bornes de la fenêtre graphique obtenue suite à ces manipulations n'étaient pas sauvegardées, comme tu pouvais le constater en les consultant via

Shift

Plot

. C'est-à-dire que dès que tu changeais de vue, le zoom que tu avais peut-être soigneusement effectué était perdu.

Nous passons maintenant à l'application de géométrie dynamique, soit au travail concernant plus précisément Bernard Parisse.

Lorsque l'on y créait des paraboles, leur branches étaient tronquées sur la représentation graphique de la vue

Plot

, n'étant pas prolongées jusqu'aux bords de l'écran contrairement aux représentations d'autres objets.

Le résultat de certains appels pouvait être différent selon qu'il était affiché sur la vue numérique (touche

Num

) ou la vue graphique (touche

Plot

).

Créons par exemple un quadrilatère ABCD qui ici sera un rectangle.
Lorsque appelée depuis la vue numérique, la fonction is_parallelogram() retournait 3, indiquant que le quadrilatère étant non seulement un parallélogramme mais également un rectangle.

Mais sur la vue graphique le résultat du même appel était tout autre, proche de 0...

Toujours dans l'application Géométrie, lorsque l'on créait des fonctions à partir d'une équation cartésienne et que l'on en demandait ensuite l'équation, parfois la réponse n'était pas trouvée, pouvant être vide ou encore contenir un message d'erreur :

De façon similaire lorsque l'on créait des fonctions implicites et que l'on en demandait ensuite l'équation, le résultat n'était pas toujours sous la forme à laquelle on aurait pu s'attendre :

Retournons au travail de Jeff avec cette fois-ci l'application Stat 1Var.

Rappelons que la HP Prime permet de configurer très librement le format d'affichage numérique, offrant même à l'utilisateur la possibilité de choisir parmi 2 séparateurs décimaux et même 4 séparateurs de milliers.

Mais le format choisi par l'utilisateur n'était pas systématiquement respecté partout. Par exemple pour l'application Stats 1Var justement, si l'on définissait une transformation de série statistique dans la vue

Symb

, cette même définition n'était pas affichée sous le même format sur la vue

Plot

, le choix du séparateur décimal étant certes respecté mais celui du séparateur de milliers ignoré :

Plot

Voici maintenant l'application Inférence.

Choisissons le test d'adéquation du χ².

Aussi bien dans la table de saisie que dans la table des résultats, le degré de liberté était mis par défaut au nombre d'observations N.

Num

Reprenons la configuration de l'écriture décimale, mais cette fois-ci dans le cadre de l'application Explorateur.

Optons donc pour une écriture utilisant la virgule comme sépérateur décimal. Dans ce cas la virgule ne peut plus être utilisée comme séparateur lors de l'appel de fonctions à plusieurs paramètres, au profit du point virgule.
Par exemple dans ce contexte pour obtenir on ne saisira plus COMB(6,2) mais COMB(6;2).

Les appels automatiques de fonctions effectués depuis les diverses interfaces en tiennent normalement compte... sauf exception.

Et justement, dans ce contexte, il y avait un problème avec l'interface d'exploration de fonctions affines et fonctions polynomiales du 3^è degré, l'ordonnée à l'origine étant remplacée par un message d'erreur.

Le système HP Prime est d'une richesse tellement exceptionnelle, que nous avons déjà vu plusieurs fois des utilisateurs regretter que l'ensemble de ses possibilités n'étaient pas entièrement documentées dans le manuel. Mais crois-le ou pas, l'inverse existe également...

Regardons du côté de l'application Suite. Selon le manuel, une variable système SeqPlot est censée nous permettre de configurer la vue graphique

Plot

, une valeur de 1 indiquant par exemple une représentation en toile (dite également en escalier ou escargot).

Sauf que problème, SeqPlot n'était pas listée dans les variables système de l'application Suite. C'est même pire que cela, SeqPlot n'existait même pas, toute saisie manuelle y faisant appel déclenchant une erreur.

Un gros défaut de la HP Prime c'est son clavier, nombre de manipulations élémentaires nécessitant de taper 2, 3 ou parfois même 4 touches.

Par exemple pour terminer la saisie d'une ligne de programme en langage HPPPL, il faut saisir un point virgule puis aller à la ligne, et donc taper

ALPHA

+

Enter

. C'est beaucoup quand c'est à faire quasiment pour chaque ligne d'un programme.

On peut également citer l'affectation de variables, nécessitant au choix la saisie de l'opérateur ► avec

Shift

EEX

, ou bien encore pire de l'opérateur := avec

ALPHA

-

Shift

.

.

Justement le moteur CAS souffrait également du défaut dans une moindre mesure, puisque nécessitant souvent la saisie de l'opérateur égal avec

Shift

.

, non seulement pour les affectations mais également pour les équations.

Le changelog officiel annonçait également une amélioration de la résolution d'inéquations polynomiales du 3^è degré.

En effet plusieurs exemples très problématiques avaient été communiqués :

• $mathjax$solve\left(x^2-2>x^3-x^2-3x-6\right)$mathjax$
  semble faire boucler indéfiniment la calculatrice, ne renvoyant jamais de résultat malgré plusieurs minutes d'attente
• $mathjax$solve\left(x^2-3x-2>x^3\right)$mathjax$
  fait même redémarrer la calculatrice sous quelques secondes

Sauf que, nuance, ces problèmes ne concernent que l'ancien modèle HP Prime G1.

Les développeurs ont dû confondre et tester sur HP Prime G2, constater qu'il n'y avait aucun problème, et déduit qu'ils avaient corrigé le problème sans le faire exprès en touchant à autre chose.

Sauf que non, le problème n'est malheureusement pas résolu, même après mise à jour la HP Prime G1 continue à boucler indéfiniment ou planter sur ces exemples.

Shift

View

Shift

Menu

Shift

Vars

Justement, taper une touche dans ce contexte lance la de saisie pinyin, méthode de saisie phonétique des caractères chinois en utilisant l'alphabet latin.

Sauf qu'il y avait ici un vilain problème d'interface. Tapons par exemple A pour aller aux premières syllabes pinyin correspondantes. Les syllabes pinyin étaient bizarrement toutes suffixées du chiffre 1. Et justement pour la syllabe a, il y avait un problème avec les onglets tactiles de bas d'écran, le choix 1 en étant absent et le choix 2 y figurant en double.

La combinaison indiquée A2 affichait ainsi ce qui correspondait à A1, et les deux combinaisons A2 n'affichaient pas la même chose :

Un problème généralisé,tous les autres choix de syllabes pinyin souffrant de bizarreries similaires dans leurs onglets tactiles de bas d'écran.

Nous n'en avons pas terminé avec la saisie pinyin.

Tapons Q pour démarrer une saisie pinyin, puis changeons d'avis en tapant B.

Dans ce dernier cas, le défilement arrière était incorrect, ne remontant pas assez loin pour montrer la syllabe sélectionnée.

Les noms de variables sur HP Prime doivent répondent à diverses règles.

Certains caractères sont interdits en première position, mais permis dans le reste du nom. C'est par exemple le cas des chiffres :

• a2b et ab2 sont des noms de variables valides
• mais 2ab n'est pas un nom de variable valide, car pouvant être confondu avec
  $mathjax$2\times ab$mathjax$

Parlons d'autres caractères :

• les opérateurs non-ASCII (signe moins, exposant 2, etc.)
• les codes de contrôle C1 (Unicode U+0080 à U+009F)

Ces caractères étaient interdits au sein des noms de variables, mais pouvaient dans certaines situations y être acceptés en première position.

Créer de tels noms de variables était impossible sur l'historique de calcul, mais était par exemple possible sur les noms de colonne, par exemple dans les applications de statistiques.

Leur utilisation ensuite dans d'autres applications ou sur l'historique de calcul pouvait se révéler problématique, ne retournant pas les bonnes valeurs ou même les remplaçant par un message d'erreur.

Le langage HPPPL (HP Prime Programming Language) dispose de toutes les fonctions nécessaires à la manipulation de chaînes de caractères. Nous pouvons citer par exemple MID(chaîne,position,longueur) qui permet d'extraire d'une chaîne de caractères une sous-chaîne :

• démarrant à une position donnée (la première position étant ici numérotée 1)
• et de longueur donnée, paramètre optionnel faisant aller par défaut jusqu'à la fin de la chaîne

Anomalie dont les programmes HPPPL devaient jusqu'à présent tenir compte, si l'on faisait démarrer la position au-delà de la fin de la chaîne de caractères, la fonction MID() arrivait à en extraire une chaîne de longueur 1 alors qu'elle aurait dû retourner une chaîne vide.

Formidable ajout de l'ultime mise à jour par HP calculatrices en 2021, les programmes prennent la forme de véritables projets car pouvant intégrer eux-mêmes divers fichiers :

• des fichiers de code pouvant être écrits dans les différents langages de la calculatrice (HPPPL, CAS ou Python) et même interagir entre eux
• des fichiers de données (image JPG ou PNG, données binaires)

Problème ainsi introduit dans le logiciel de connectivité, si l'on supprimait tous les fichiers d'un projet, le menu contextuel continuait malgré tout à proposer la possibilité de renommer, dont le choix plantait alors le logiciel.

Autre problème avec les programmes HP Prime, lorsque l'on collait du code provenant d'une source externe dans la calculatrice virtuelle ou dans le logiciel de connectivité.

Rappelons que les fichiers de projet .hpprgm ne sont pas des fichiers texte mais des fichiers binaires.

Or selon la source sur laquelle le code avait été copié, ce dernier pouvait intégrer des caractères spéciaux et notamment des espaces insécables. Les fichiers .hpprgm ainsi générés étaient inutilisables sur la calculatrice virtuelle ou si transférés sur une calculatrice physique, générant des erreurs de syntaxe qui étaient fort difficiles à comprendre et donc corriger, puisque l'affichage du code ne montrait rien d'anormal.

Symb

Plot

Num

Que dire ?

Certainement du travail conséquent de la part de Jeff Tupper, qui n'avait développé qu'une application HP Prime isolée et a dû s'auto-former sur le système HP Prime, clairement le système le plus complexe tous modèles graphiques confondus avec ses très hautes possibilités d'intégration et interactions.

Mais d'un autre côté n'apportant rien de nouveau et ne faisant que corriger des bugs bien mineurs, tout ceci après 15 mois d'attente depuis la mise à jour Moravia précédente qui était complètement sans le moindre intérêt, ou 2 ans d'attente depuis l'ultime mise à jour HP calculatrices. C'est très insuffisant, une mise à jour extrêmement décevante.

Pour rendre cet avis plus objectif, prenons en référence le nombre de commits annuels réalisés sur le projet HP Prime.

Comme on pouvait s'y attendre on constate bien que HP a quasiment mis le développement à l'arrêt à compter de 2019, avec le nombre de commits chutant brutalement de plusieurs milliers à :

• 160 en 2019
• 92 en 2020
• 170 en 2021

Avec 127 commits en 2023 nous ne sommes même pas encore au niveau de ce développement "à l'arrêt", surtout qu'en prime ce nombre de commits est à diviser par deux car correspondant au travail de 2 années, puisqu'aucune mise à jour n'est sortie en 2022.

La mise à l'arrêt du développement HP Prime en 2019 en pleine réforme du lycée en France fut une erreur gravissime de la part de HP (erreur dont HP est hélas coutumier), ayant conduit la HP Prime à être la dernière machine toute concurrence confondue à obtenir l'application Python nécessaire, in extremis grâce au travail acharné de Cyrille de Brébisson juste avant la cession à Moravia. Cela dégradait déjà grandement l'image du projet.

Moravia a hélas fait le choix d'investir encore moins que HP dans le développement HP Prime. Sauf qu'en 2021 nous ne récupérions qu'une application Python insuffisante dans le contexte scolaire français (contrairement à l'ensemble de la concurrence pas de bibliothèque matplotlib pour les représentations dans un repère notamment en Physique-Chimie, pas de bibliothèque de tracé à la tortue turtle pour les Secondes...). Et depuis 2021, rappelons que la concurrence ne s'est absolument pas mise en pause. Bref, le retard sur la concurrence que la HP Prime avait commencé à rattraper en 2021 suite aux efforts surhumains de Cyrille, Moravia s'est empressé de le refaire perdre à nouveau, et peut-être cette fois-ci de façon fatale.

Rappelons de plus que contrairement à toute la concurrence, l'application Python introduite en 2021 est instable, générant nombre de crash de la calculatrice, et que ce problème ne semble pas avoir été adressé avec cette dernière mise à jour.

Rappelons que l'incurie de Moravia a déjà réussi à faire perdre aux calculatrices graphiques HP le marché portugais (2021) ainsi que le marché australien (2022). Et quand un marché est perdu, il est extrêmement difficile voir impossible de le récupérer, la confiance des utilisateurs et institutions étant durablement entâchée.

À moins que le projet de Moravia ne se résume à continuer à vendre de plus en plus cher à une niche de fans/collectionneurs/nostalgiques/pigeons comme SwissMicro, Moravia doit immédiatement réagir et décupler son investissement de développement du projet HP Prime, afin que Jeff puisse consacrer davantage de temps et d'énergie au projet, voir même être accompagné d'autres développeurs aux compétences également exceptionnelles. Parce qu'en l'état après 2 ans d'attente, c'est littéralement se moquer du monde.

Il s'agit probablement de notre dernier avertissement sincère, partagé en toute bienveillance même si l'entité en question ne semble en avoir rien à faire, vu le plus grand mépris qu'elle oppose fort incorrectement à la moindre tentative de contact depuis 2018. Il sera bientôt définitivement trop tard pour espérer pouvoir revenir sur le marché français, nous ne pourrons alors plus être que spectateurs et entonner "c'est la chute finale".