Surprise, dans la lancée de la sortie de sa
mise à jour 2.00 majeure pour
Graph Math+,
Casio nous publie aujourd'hui un script
Python pour
Graph Math+.
Il s'agit d'un
solveur graphique d'équations différentielles, également compatible avec les
fx-CG100 et
fx-1AU Graph, modèles équivalents hors de France.
Le manuel l'appelle
Diff-Eq 1.0, mais le code
Python inclut un nom plus complet :
Slope Field Graph 1.0.
L'application en question se compose de 3 scripts
Python que tu dois copier dans un même dossier au choix de ta calculatrice, et c'est ensuite le script
DEQexe.py que tu dois lancer.
Il te demande alors de saisir ton équation différentielle ainsi que les bornes de la fenêtre, et t'affiche alors le champ de vecteurs des solutions :
Comme clairement indiqué à l'écran, tu es ensuite invité à taper [OK] pour saisir des conditions initiales et visualiser simultanément jusqu'à 3 solutions particulières :
C'est donc la toute première fois que
Casio nous sort un élément additionnel codé en
Python.
Avec la suppression du support des applications additionnelles en langage machine sur
Graph Math+, nous nous demandions bien comment
Casio allait faire pour continuer à proposer des fonctionnalités additionnelles.
Apparemment jusqu'ici il y a donc 2 approches :
- pour les fonctionnalités nécessitant du code en langage machine et donc sensibles, comme nous avons vu avec la mise à jour 2.00 une intégration a priori en dur dans le système d'exploitation
- et pour les autres, un codage en Python
Attention, le code
Python de
Diff-Eq 1.0 utilise la fonction de test de touche
getkey(), et n'est donc malheureusement pas compatible avec les anciens modèles programmables en
Python.
Et bien bonne nouvelle, nous avons le plaisir de t'offrir une version modifiée,
Diff-Eq 1.0 "compatible edition" ciblant les anciennes
Casio Graph programmables en
Python.
La fonction
getkey() ne servait ici qu'à détecter la pression de la seule touche [OK].
Nous contournons l'absence de cette fonction en interceptant l'exception
KeyboardInterrupt déclenchée lorsque tu tapes la touche [AC].
Sur
Graph 90+E et
fx-CG50, il te suffit donc, comme nous l'indiquons, de taper [AC] au lieu de [OK].
Nous en profitons pour rajouter également la compatibilité avec l'écran monochrome des
Graph 35+E II et
fx-9750/9860GIII.
Outre l'absence de couleur cela implique également une réduction de la définition de l'écran, on passe de
384×192 pixels à
128×64 pixels. L'idée est donc de diviser à peu près toutes les coordonnées d'affichage en pixels par 3, puis d'effectuer quelques ajustements ou allègements pour la lisibilité puisque nous n'avons plus que 2 couleurs pour afficher : noir et blanc.
En prime pas besoin de t'embêter à choisir entre différents fichiers, notre version détecte automatiquement la présence ou absence de la fonction
getkey() ainsi que le caractère couleur ou monochrome de l'écran, et s'adapte automatiquement !
Citer : Posté le 23/12/2024 23:20 | #
Eh beh, c'est étonnamment élaboré !
J'ai pas tout lu encore mais vu le code de Line() c'est clair qu'ils ont pas vu ton super exposé sur comment faire ça efficacement.
Je me demandais comment ils faisaient pour parser les expressions en entrée, mais évidemment ils le font pas, ils utilisent juste eval(). x)
Citer : Posté le 24/12/2024 12:40 | #
C'est pas mal du tout en fait. Un truc déstabilisant c'est d'écrire Y'= avec un Y majuscule alors qu'ensuite c'est un y minuscule qui est attendu. Sinon, l'affichage est bon avec 16*8=128 petites tangentes, le calcul est une version plus évoluée que Runge-Kutta 4, il utilise des tableaux de Butcher avec un test de tolérance sur le pas, mais pas le même que KhICAS. Je n'ai rien vu dans l'UI qui permette de récupérer la valeur finale de la solution approchée (comme odesolve dans KhiCAS).
Niveau efficacité, j'ai regardé rapidement avec y'=sin(t*y) (Y'=sin(x*y) sur la Casio). Il faut environ 10 secondes pour tracer le champ des tangentes et 2 solutions, environ 2 fois plus qu'avec KhiCAS. Mais KhiCAS trace environ 2 fois plus de petites tangentes, je pense qu'avec une résolution identique, on doit pouvoir faire 4 fois plus rapide que ce programme (et accessoirement on devrait pouvoir choisir la condiition initiale sur le graphe donnant le champ des tangentes, c'est possible dans Xcas, il faudrait faire une UI dédiée sur la Casio dans les apps de KhiCAS). Donc ça reste suffisamment efficace, ce qui n'est pas si étonnant que ça vu que le cout du calcul est principalement porté par le temps pour calculer f(t,y).
Quel est le public cible? Surement pas le lycée en France où la notion de champ des tangentes est absent (sauf erreur de ma part), et dans le supérieur les calculatrices sont presque partout interdites. Je pense que c'est plutot pour la fxcg100. La mauvaise nouvelle, c'est que ça confirme s'il en était besoin que Casio va défendre l'idée que les programmes tiers c'est du Python maintenant.
Citer : Posté le 25/12/2024 09:29 | #
Eh beh, c'est étonnamment élaboré !
C'est pas mal du tout en fait.
Effectivement, ils se sont donné du mal et il doit bien y avoir une raison. À se demander quelle est la cible.
Par contre, ce sera indisponible en mode examen.
J'ai pas tout lu encore mais vu le code de Line() c'est clair qu'ils ont pas vu ton super exposé sur comment faire ça efficacement.
J'ai remarqué aussi en survolant du code de tracé de segments peu heureux.
Mais je n'y ai pas touché, je me suis contenté de modifications mineures pour la compatibilité, afin de pouvoir les réappliquer facilement en cas de mise à jour par Casio.
Quel est le public cible? Surement pas le lycée en France où la notion de champ des tangentes est absent (sauf erreur de ma part), et dans le supérieur les calculatrices sont presque partout interdites. Je pense que c'est plutot pour la fxcg100.
Je pense aussi que la cible est autre que la France.
Mais ce doit être une cible particulièrement intéressante, c'est cela qui m'intrigue.
Citer : Posté le 25/12/2024 10:05 | #
La mauvaise nouvelle, c'est que ça confirme s'il en était besoin que Casio va défendre l'idée que les programmes tiers c'est du Python maintenant.
Cela me rappelle quand TI a supprimé le support des programmes dits ASM (en langage machine) sur TI-83 Premium CE et TI-84+CE à l'occasion de la mise à jour 5.5 au printemps 2020 (et je rappelle que chez TI toute mise à jour est sans retour).
La communauté de développement était très contrariée, et il leur avait été répondu en gros "vous n'avez qu'à faire en Python".
Certes, contrairement à Casio, le Python des CE dispose d'une belle collection de bibliothèques très fournies.
Mais cela témoignait justement du mépris ou de la méconnaissance des projets communautaires, car il était totalement impossible que cela marche.
Je rappelle que l'interpréteur CircuitPython modifié (un MicroPython allégé) des calculatrices CE tourne sur un coprocesseur dédié avec des mémoires RAM/ROM dédiées et limitées (au sein du même microcontrôleur).
Nous n'avons que 20K de heap, une fois les bibliothèques Python nécessaires importées il ne reste quasiment plus rien pour coder autre chose qu'une simple petite boucle bien scolaire.
Impossible d'imaginer un projet Python pour CE qui arrive ne serait-ce qu'à la cheville des projets ASM.
La rentrée 2020 fut très dure pour TI, car la communauté a très vivement réagi, et y a passé en secret (de façon concertée ou non, je l'ignore) tout son été :
C'est la toute première fois de ma vie que j'ai vu TI reculer.
Ils n'ont pas remis le support des programmes ASM, mais depuis ils n'ont jamais cherché à corriger la faille exploitée par arTIfiCE.
4 ans après, Casio semble à son tour tenter de faire ce sur quoi TI n'a pas réussi : on supprime le support des applications additionnelles en langage machine (pensant améliorer la sécurité) et on dit à la communauté qu'ils ont le Python.
Certes nous avons ici 1M de heap, mais il y a d'autres choses bloquantes.
L'absence d'une fonction getkey() sur Graph 90+E et fx-CG50 a enfin été corrigée sur Graph Math+, et on apprécie le double buffering.
Mais la bibliothèque graphique casioplot reste très pauvre, n'offrant pour les tracés rien de plus évolué qu'un set_pixel(x, y). Les tracés de toute autre forme doivent donc être codés en Python avec des boucles d'appels set_pixel(), et des performances à l'affichage absolument désastreuses.
Il n'y a donc, de mon point de vue et à ce jour, aucune raison que cela soit davantage une réussite que chez TI. Si on veut faire passer de force sa communauté au Python, il faut au minimum s'en donner les moyens avec un Python qui donne envie et facilite les choses au lieu de mettre des bâtons dans les roues...
C'est donc soit que Casio pense être capable de faire mieux que TI, soit que Casio ignore l'épisode précédent.
Et la voie diplomatique a déjà été tentée depuis l'année dernière, et comme vous pouvez le constater sans succès.
Seule reste l'attaque maintenant, la communauté semble s'orienter dans cette voie avec un jailbreak à venir qui me semble pour le moment bien gentil.
Mais malgré cela ce n'est pas pour autant que Casio réagira forcément mieux que TI. J'ignore ce que ça donnera, mais il ne faut juste pas oublier que la mentalité japonaise diffère de la mentalité américaine.
Citer : Posté le 25/12/2024 10:22 | #
D'une manière générale, pour une entreprise quelle qu'elle soit, le seul indicateur de rétroaction c'est le marché.
A un instant t, une décision est prise, bonne ou mauvaise. Il y a toujours des mécontents, mais la remise en cause ou pas d'une décision relève toujours de l'analyse d'impact, c'est à dire si l'effet est productif au global, on garde, peut importe les dommages collatéraux, si le préjudice est important, on avise sur cette fameuse décision. Et dans ce cas là, c'est la performance du marketing qui est primordiale.
Donc si un bashing / action communautaire fonctionne, c'est qu'elle a un impact important sur le bénéfice de l'entreprise. Sinon globalement si ça se limite à 4/5 tondus qui pleurent dans leur coin, alors à mon sens il n'y aura pas de retour en arrière.
Citer : Posté le 25/12/2024 23:16 | #
En ce qui me concerne, vu que Casio France après m'avoir proposé de porter KhiCAS sur la 35eii, m'avoir soutenu via le don d'une 90 et d'une 35eii, a brusquement décidé de bloquer KhiCAS, il est bien évident que la seule réponse possible c'est de conseiller aux gens d'acheter des 90, des 35eii ou de passer à la concurrence (et c'est une des raisons qui m'a poussé à porter KhiCAS sur les applications externes des Numworks, ou sur les ti83/84), en espérant que d'autres se joindront pour influer sur les chiffres de vente de la math+ (et bientot de la fxcg100), qui est le seul indicateur que les décideurs chez Casio vont regarder. On ne connait évidemment pas globalement le blian de la math+ en France, mais ce qui est public ne me semble pas très brillant: le score de ventes chez amazon est resté à 50+ ventes mensuelles, donc entre 300 et 600 ventes sur juillet-décembre 2024. Par exemple ce soir, la math+ est en 14ème position des meilleures ventes, alors qu'elle est vendue à 73.55€, et derrière la 90 (pourtant indisponible!). 13ème à la fnac, derrière la ti83 ce (l'ancien modèle, pas la version Python), il est vrai que le prix y est indécent.
C'est probablement plus difficile pour un site comme planete casio de se positionner comme moi, car il dépend j'imagine au moins partiellement du support de Casio France.