Chaque constructeur de calculatrices a choisi de fabriquer sa propre bibliothèque permettant de contrôler directement les pixels de l'écran.
C'est à dire que quand tu choisis de développer un script Python pour l'une de ces 3 bibliothèques, il sera alors incompatible avec tous les autres modèles.
A moins de t'embêter à publier une édition différente de ton script pour chaque modèle existant ou à venir...
A vous lire vous êtes nombreux à déplorer cette situation sur notre site ainsi que sur les réseaux sociaux, aussi bien lycéens qu'étudiants ou enseignants.
Nous le regrettons également, nous aurions préféré que les constructeurs adoptent au choix :
- kandinsky sur NumWorks
- casioplot sur Casio Graph 90/35+E II
- ti_graphics sur TI-83 Premium CE Edition Python
C'est à dire que quand tu choisis de développer un script Python pour l'une de ces 3 bibliothèques, il sera alors incompatible avec tous les autres modèles.
A moins de t'embêter à publier une édition différente de ton script pour chaque modèle existant ou à venir...
A vous lire vous êtes nombreux à déplorer cette situation sur notre site ainsi que sur les réseaux sociaux, aussi bien lycéens qu'étudiants ou enseignants.
Nous le regrettons également, nous aurions préféré que les constructeurs adoptent au choix :
- un standard
- ou alors des spécifications compatibles avec la première bibliothèque sortie sur calculatrice (kandinsky)
- ou sinon se mettent d'accord sur des spécifications communes à l'avenir
Mais voici aujourd'hui une solution que nous t'avons concoctée, PPN, pour PolyPyNet (abrégé du français PolyPythonnettes), une bibliothèque pour les unifier toutes !
Non non, il ne s'agit absolument pas d'une bibliothèque graphique supplémentaire.
C'est en fait une bibliothèque de compatibilité. C'est ultra simple à utiliser pour toi, que tu sois utilisateur ou développeur :
Enfin pour t'offrir un maximum de liberté, tu peux aussi bien distribuer la bibliothèque PPN avec tes propres scripts, qu'inviter tes utilisateurs à aller la récupérer séparément.
Non non, il ne s'agit absolument pas d'une bibliothèque graphique supplémentaire.
C'est en fait une bibliothèque de compatibilité. C'est ultra simple à utiliser pour toi, que tu sois utilisateur ou développeur :
- Utilisateur, il te suffit de charger les fichiers de PPN sur ta calculatrice et c'est tout, plus besoin de t'en occuper.
- Développeur, tu as juste à remplacer le nom de module constructeur dans tes lignes d'importation par ppn et c'est tout, rien d'autre à changer dans ton script, tu continues à coder avec les fonctions de ta bibliothèque graphique préférée, que ce soit casioplot, kandinsky ou ti_graphics.
Enfin pour t'offrir un maximum de liberté, tu peux aussi bien distribuer la bibliothèque PPN avec tes propres scripts, qu'inviter tes utilisateurs à aller la récupérer séparément.
Nous allons t'illustrer cela avec un exemple de suite. Voici une animation de radar codée en Python par Dark Storm pour Casio Graph 90+E.
Codé à l'occasion du concours de démo graphiques en Python par Planète Casio.
Un script a priori assez conséquent de près de 5K.
Et bien il suffit de remplacer comme indiqué les lignes d'importation
Certes les définitions d'écran sont différentes et tout ne peut pas être adapté automatiquement. Mais si tu codes pour la bibliothèque PPN tu pourras récupérer automatiquement les dimensions de l'écran de la plateforme exécutant ton script en appelant après importation les variables ppn_w et ppn_h, et en tenir compte.
Mais à ce détail près, c'est quand même impressionnant d'avoir un script aussi conséquent qui tourne sur toutes les machines après s'être seulement donné la peine de changer une simple ligne d'importation !
Parlons un petit peu performances. Précisons que les scripts utilisant PPN ne permettent pas de réaliser de classement pertinent. En effet, un même appel graphique n'est en interne pas exécuté de la même façon selon le modèle utilisé :
Mais ce n'est pas une raison pour ne pas te dire ce que ça donne, pour 1 tour de radar complet :
Codé à l'occasion du concours de démo graphiques en Python par Planète Casio.
Un script a priori assez conséquent de près de 5K.
Et bien il suffit de remplacer comme indiqué les lignes d'importation
from casioplot import ...
par from ppn import ...
, et ça marche direct sur tous les autres modèles couleur NumWorks, TI-83 Premium CE Edition Python et TI-Nspire Ndless ! Certes les définitions d'écran sont différentes et tout ne peut pas être adapté automatiquement. Mais si tu codes pour la bibliothèque PPN tu pourras récupérer automatiquement les dimensions de l'écran de la plateforme exécutant ton script en appelant après importation les variables ppn_w et ppn_h, et en tenir compte.
Mais à ce détail près, c'est quand même impressionnant d'avoir un script aussi conséquent qui tourne sur toutes les machines après s'être seulement donné la peine de changer une simple ligne d'importation !
Parlons un petit peu performances. Précisons que les scripts utilisant PPN ne permettent pas de réaliser de classement pertinent. En effet, un même appel graphique n'est en interne pas exécuté de la même façon selon le modèle utilisé :
- redirection directe vers la fonction graphique constructeur si le script est exécuté sur la plateforme pour laquelle il a été initialement développé
- passer à travers une ou plusieurs fonctions de compatibilité si le script est exécuté sur une autre plateforme que celle pour laquelle il a été initialement développé
Mais ce n'est pas une raison pour ne pas te dire ce que ça donne, pour 1 tour de radar complet :
- 3.2754s: NumWorks N0110 (firmware tiers Omega)
- 3.4296s : NumWorks N0100
- 3.5284s : NumWorks N0110
- 3.6286s : NumWorks N0100 (firmware tiers Omega)
- 6.499s : Graph 90+E
- 7.412s : TI-Nspire CX CR3-
- 9.703s : TI-Nspire CX CR4+
- 41min08.685s : TI-83 Premium CE Edition Python (lire plus bas pour des détails)
On retrouve le problème déjà évoqué pour la TI-83 Premium CE Edition Python, à savoir que le Python tourne sur un coprocesseur, et que toute instruction graphique doit donc transiter par le processeur principal avant d'atteindre l'écran, ce qui génère une latence à chaque appel graphique.
Comme ici l'animation du radar travaille avec des boucles de set_pixel, le code équivalent est sans surprise catastrophique sur TI-83 Premium CE Edition Python.
Texas Instruments fournit heureusement une solution exclusive avec des fonctions de tracé de divers primitives et formes géométriques (lignes, polygones...), qui pourraient avantageusement être utilisées ici, permettant de regrouper en un seul appel graphique des transformations de plusieurs et même plein de pixels.
Mais voilà, cela nécessiterait à la différence une conversion manuelle du code, faite plus bas sur ce topic pour comparer, mais qui s'éloigne du thème de la compatibilité automatique sans effort que nous souhaitions traiter ici.
Comme ici l'animation du radar travaille avec des boucles de set_pixel, le code équivalent est sans surprise catastrophique sur TI-83 Premium CE Edition Python.
Texas Instruments fournit heureusement une solution exclusive avec des fonctions de tracé de divers primitives et formes géométriques (lignes, polygones...), qui pourraient avantageusement être utilisées ici, permettant de regrouper en un seul appel graphique des transformations de plusieurs et même plein de pixels.
Mais voilà, cela nécessiterait à la différence une conversion manuelle du code, faite plus bas sur ce topic pour comparer, mais qui s'éloigne du thème de la compatibilité automatique sans effort que nous souhaitions traiter ici.
Téléchargements :
- Radar + PolyPyNet
- PolyPyNet (dernière version)
Crédits images :