TI-Planet | News

by **critor** » 15 Aug 2021, 22:37

Quelle Calculatrice Choisir 2021 édition Universelle

Épisode 4 - Écrans et zone graphique utile

Pour fêter les 10 ans de TI-Planet en cette rentrée 2021, nous te publions la base de données intégrale de nos classements de rentrée QCC organisés depuis la rentrée 2015.

Nous en profitons de plus pour te réaliser le travail titanesque d'étendre les tests aux modèles plus anciens :

toutes les calculatrices graphiques Texas Instruments (depuis la première TI-81 de 1990)
toutes les calculatrices graphiques Casio à technologie Flash (depuis 2003)

Ce qui donne pas moins de 132 modèles différents de calculatrices testés sous toutes leurs coutures, 10 ans de tests et découvertes à porté de clic !

Dans un épisode précédent, nous t'avons révélé les définitions en pixels des écrans de nos calculatrices graphiques.

Mais la définition ne fait pas tout, faut-il encore pouvoir utiliser les pixels en question. Bien souvent ce n'est qu'une partie de l'écran qui comporte des pixels contrôlables par l'utilisateur (c'est-à-dire allumables dans la couleur ou teinte souhaitée). Nous appellerons cette partie de l'écran zone graphique utile.

Nous allons donc déterminer la taille en pixels de la zone graphique utile de chaque modèle. Pour aujourd'hui nous le ferons dans le contexte du tracé de graphes, ainsi que de l'exécution de programmes en langage constructeur (hors Python donc).

Dans la plupart des cas, il nous suffira d'effectuer 2 simples calculs :

$mathjax$\frac{x_{max}-x_{min}}{Δx}+1$mathjax$
$mathjax$\frac{y_{max}-y_{min}}{Δy}+1$mathjax$

x_min et x_max étant les bornes horizontales de la fenêtre graphique, y_min et y_max les bornes verticales, Δx la distance entre 2 pixels sur l'axe horizontal, et Δy la distance entre 2 pixels sur l'axe vertical

Les Lexibook GC3000FR et Esquisse GCEXFR offrent un écran de 47×32+40×8 pixels + 33 drapeaux.

Que contrôle-t-on dans tout ça ? Déjà pas grand chose car la machine n'est pas programmable malgré la présence trompeuse d'une touche

PROG

au clavier, une inadéquation manifeste aux programmes scolaires, et encore ce n'est même pas le pire de ses défauts de ce point de vue...

Bref pour tester la zone graphique (in)utile, il ne nous reste plus que les graphiques. Par défaut nous avons donc un repère orthonormal, avec un pas de 0.2 entre deux pixels horizontaux ou verticaux.
Récupérons les bornes de la fenêtre, une par une car la technologie archaïque qu'il semble y avoir sous le capot est incapable d'afficher simultanément plusieurs nombres à l'écran :

Allons-y pour les calculs :

$mathjax$\frac{\left(4.6-\left(-4.6\right)\right)}{0.2}+1=\frac{\left(4.6+4.6\right)}{0.2}+1\\
\phantom{\frac{\left(4.6-\left(-4.6\right)\right)}{0.2}+1}=\frac{9.2}{0.2}+1\\
\phantom{\frac{\left(4.6-\left(-4.6\right)\right)}{0.2}+1}=46+1\\
\phantom{\frac{\left(4.6-\left(-4.6\right)\right)}{0.2}+1}=47$mathjax$
$mathjax$\frac{\left(3-\left(-3\right)\right)}{0.2}+1=\frac{\left(3+3\right)}{0.2}+1\\
\phantom{\frac{\left(3-\left(-3\right)\right)}{0.2}+1}=\frac{6}{0.2}+1\\
\phantom{\frac{\left(3-\left(-3\right)\right)}{0.2}+1}=30+1\\
\phantom{\frac{\left(3-\left(-3\right)\right)}{0.2}+1}=31$mathjax$

Zone graphique utilisable donc de 47×31 pixels.
Oui, la zone matricielle correspondant sur l'écran faisant 32 pixels de hauteur, il y a donc physiquement et bêtement une ligne de 47 pixels qui ne s'allument jamais...

Ce qui nous permet en passant de dénoncer un autre mensonge de l'emballage et du manuel, si tu comptes bien la sinusoïde donnée en exemple y est en effet tracée sur une zone graphique 48×32 pixels, soit une surestimation de plus de 5%... Forcément avec ça, la sinusoïde réellement obtenue est loin d'être aussi belle que celle de l'emballage...

Comment peut-on avoir un packaging aussi mensonger, aussi trompeur, sans le faire exprès ?...

Les TI-82 Advanced et TI-84 Plus T t'offrent donc un écran monochrome 96×64 pixels.

Effectuons notre calcul :

Code: Select all: (Xmax-Xmin)/PasX+1 (Ymax-Ymin)/PasY+1

La zone graphique contrôlable par l'utilisateur est pour sa part de 95×63 pixels soit 97,41% !

Les TI-82 Advanced Edition Python, TI-83 Premium CE et TI-84 Plus CE t'offrent un écran couleur 320×240 pixels.

De même :

Code: Select all: (Xmax-Xmin)/ΔX+1 (Ymax-Ymin)/ΔY+1

La zone graphique utile pour les graphes et programmes est ici de 265×165 pixels, soit seulement 56,93%, à peine plus de la moitié des pixels !

Les Casio Graph 25+E, Graph 35+E et Graph 75+E ont un écran de 128×64 pixels.

Il n'y a ici pas de variable système équivalente au Δy pour notre calcul, mais on peut se débrouiller en faisant attention à bien avoir un repère orthonormal, ce qui est justement le cas par défaut :

Code: Select all: (Xmax-Xmin)/Xdot+1 (Ymax-Ymin)/Xdot+1

La zone graphique utile pour l'utilisateur est ici de 127×63 pixels soit 97,41% !

La Casio Graph 90+E t'offre un écran de 396×224 pixels.

Même difficulté que l'on contourne comme pour les modèles précédents :

Code: Select all: (Xmax-Xmin)/Xdot+1 (Ymax-Ymin)/Xdot+1

La zone graphique contrôlable par les graphes et programmes est ici de 379×187 pixels soit seulement 79,90%.

La Casio fx-92+ Spéciale Collège intègre un écran de 192×63 pixels et 20 drapeaux.

La calculatrice est programmable dans un langage orienté tracé, avec des déplacements spécifiés en pixels. Nous pouvons donc ici tenter de dessiner un rectangle le plus grand possible :

Code: Select all: ?→A ?→B Stylo relevé Tourner de ↺ 180 degrés Avancer de Ent(A÷2pixels Tourner de ↺ 90 degrés Avancer de Ent(B÷2pixels Stylo écrit Répéter 2 Tourner de ↺ 90 degrés Avancer de A pixels Tourner de ↺ 90 degrés Avancer de B pixels ⤴

C'est en saisissant 191 et 46 que l'on arrive à tracer le plus grand rectangle, ce qui correspond donc à une zone graphique contrôlable de 192×47 pixels, soit 74,48% de la zone matricielle de l'écran.

Les TI-Nspire, qu'elles soient à écran couleur ou monochrome, nous offrent toutes 320×240 pixels.

Pour déterminer la taille de la zone graphique utile, nous pouvons reprendre la technique précédente de tracé de rectangle :

Code: Select all: Define test(longueur, largeur)= Prgm SetColor 255, 0, 0 DrawRect 0, 0, longueur, largeur EndPrgm

C'est en appelant test(317, 211) que l'on arrive à tracer le plus grand rectangle, ce qui correspond donc à une zone graphique utilisateur de 318×212 pixels, soit 87,78% de l'écran.

La HP Prime t'offre un écran de 320×240 pixels.

Reprenons la méthode du rectangle :

Code: Select all: EXPORT test(long, larg) BEGIN RECT_P(0, 0, long, larg, #FF0000h, #FF000000h); WAIT(); END;

C'est l'appel test(319, 239) qui nous affiche le plus grand rectangle rentrant dans l'écran. Cela correspond donc à une zone graphique utilisateur de 320×240 pixels, soit 100% de l'écran !

La Casio fx-CP400+E inclut niveau définition de loin le meilleur écran tous modèles confondus, 320×528 pixels.

Niveau zone graphique utile maintenant, c'est compliqué, ou plutôt ça dépend.

Code: Select all: (xmax-xmin)/xdot+1 (ymax-ymin)/ydot+1

En orientation portrait nous avons par défaut 309×185 pixels.

Si tu te donnes la peine de redimensionner la fenêtre graphique en pleine page à l'aide du bouton tactile physique Resize en bas d'écran, ce seront 309×401 pixels.

Tu peux également utiliser ta calculatrice en orientation paysage. Mais pas d'accéléromètre ici et donc rien d'automatique, c'est le bouton tactile physique Resize en bas d'écran qui est à utiliser ici à chaque fois que tu souhaites changer, un peu comme sur la console portable Lynx d'Atari.

Par défaut tu disposes dans ce sens d'une zone graphique de 517×81 pixels, une zone que nous trouvons bien trop écrasée et donc peu adaptée à étudier autre chose que des fonctions trigonométriques.

Si tu redimensionnes en pleine page, tu peux étendre la chose à 517×193 pixels

Bref, que retenir de tout ça pour confrontation à la concurrence ?

Déjà on peut préciser qu'il est impossible d'exécuter des programmes en orientation paysage, donc autant prendre l'orientation portrait commune.
Optons donc pour les 309×401 pixels, soit 73,33%.

La NumWorks t'apporte un écran de 320×240 pixels.

Pour les graphes nous n'avons pas trouvé de moyen automatique de mesurer la fenêtre graphique. Alors tant pis comptons les pixels à la main, ci-contre 320×204 pixels, soit 85%.

Les mesures sont facilement comparables sur le lien ci-dessous, et même disponibles pour bien d'autres modèles plus anciens :

Accès QCC 2021 Universel

by **critor** » 16 Aug 2021, 16:27

Quelle Calculatrice Choisir 2021 édition Universelle

Épisode 5 - Python et tas (heap)

Pour fêter les 10 ans de TI-Planet en cette rentrée 2021, nous te publions la base de données intégrale de nos classements de rentrée QCC organisés depuis la rentrée 2015.

Nous en profitons de plus pour te réaliser le travail titanesque d'étendre les tests aux modèles plus anciens :

toutes les calculatrices graphiques Texas Instruments (depuis la première TI-81 de 1990)
toutes les calculatrices graphiques Casio à technologie Flash (depuis 2003)

Ce qui donne pas moins de 132 modèles différents de calculatrices testés sous toutes leurs coutures, 10 ans de tests et découvertes à portée de clic !

Les interpréteurs MicroPython ou similaires qui tournent sur calculatrices font appel à différents types de mémoires :

La mémoire de stockage comme son nom l'indique stocke physiquement tes scripts Python.
La pile (stack) référence, à l'exécution, les objets Python créés. Sa capacité limite donc le nombre d'objets Python pouvant coexister simultanément en mémoire.
Le tas (heap) stocke, à l'exécution, le contenu des objets Python créés. Il limite donc la taille globale utilisée pour les données de ces différents objets.

Aujourd'hui nous allons donc nous intéresser au heap. Cet espace est extrêmement important et surtout sur les plateformes nomades, car contrairement à d'autres langages les objets Python les plus simples ont le défaut d'être assez gros. Ce sera bien souvent le heap le facteur le plus limitant pour tes projets Python, d'où son caractère essentiel.

Le temps de construire notre protocole de test, concentrons-nous sur la TI-83 Premium CE Edition Python.

Nous avons justement la chance ici de disposer du module gc (garbage collector - ramasse miettes), avec plusieurs fonctions bien utiles :

gc.collect() pour nettoyer le heap en supprimant les valeurs d'objets Python qui ne sont plus référencées
gc.mem_alloc() pour connaître la consommation du heap en octets
gc.mem_free() pour connaître l'espace heap disponible en octets

Exécutons donc le petit script suivant afin de découvrir la capacité heap Python de la TI-83 Premium CE Edition Python :

Code: Select all: import gc a, f = gc.mem_alloc(), gc.mem_free() (a, f, a + f)

Nous avons donc sur TI-83 Premium CE Edition Python une capacité heap de 19,968 Ko.

Mais lorsque l'on accède à l'environnement Python, nombre de choses sont initialisées et ce heap n'est pas vide. Plus que 17,104 Ko de libres.

Précisons que cet espace libre a de plus ici été amputé de par notre importation du module gc. Ce module n'étant hélas disponible que sur une minorité de Pythonnettes, il va nous falloir procéder autrement, surtout si l'on souhaite obtenir des mesures comparables.

Donnons quelques éléments de taille en mémoire d'objets Python usuels, du moins sur les plateformes 32 bits que sont nos calculatrices :

pour un entier nul : 24 octets déjà...
pour un entier court non nul (codable sur 31 bits + 1 bit de signe) : 28 octets
pour un entier long :
- 28 octets
- + 4 octets pour chaque groupe de 30 bits utilisé par son écriture binaire au-delà des 31 bits précédents
pour une chaîne :
- 49 octets
- + 1 octet par caractère
pour une liste :
- 64 octets
- + 8 octets par élément
- + les tailles de chaque élément

Voici une fonction qui retourne la taille d'un objet selon ces règles :

Code: Select all: def size(o): t = type(o) s = t == str and 49 + len(o) if t == int: s = 24 while o: s += 4 o >>= 30 elif t == list: s = 64 + 8*len(o) for so in o: s += size(so) return s

Nous allons donc tenter plutôt de remplir le heap avec plusieurs objets que nous allons faire grandir chacun son tour jusqu'à déclenchement d'une erreur, et retourner la capacité maximale que nous avons réussi à consommer. Voici donc un script en ce sens :

Code: Select all: def mem(v=1): try: l=[] try: l.append(0) l.append(0) l.append("") l[2] += "x" while 1: try: l[2] += l[2][l[1]:] except: if l[1] < len(l[2]) - 1: l[1] = len(l[2]) - 1 else: raise(Exception) except: if v: print("+", size(l)) try: l[0] += size(l) except: pass try: l[0] += mem(v) except: pass return l[0] except: return 0

Exécuter ce script va ainsi nous permettre d'évaluer équitablement tous les modèles.

L'appel mem(0) semble marcher comme souhaité, retournant une valeur qui peut comme prévu légèrement dépasser les 17,104 Ko trouvés plus haut.

Mais voilà autre petit problème, le résultat n'est pas toujours le même, dépendant en effet de l'état du heap lors de l'appel. Rien que sur les résultats ci-contre, nous avons une marge d'erreur de 1 à 2%.

C'est beaucoup, en tous cas suffisamment pour inverser injustement des modèles au classement. Or nous tenons à être aussi précis que possible, afin justement de produire un classement aussi équitable que possible.

Certes, on pourrait nettoyer le heap avant chaque appel avec gc.collect(), mais ce ne serait pas juste puisque nous n'aurons pas cette possibilité sur nombre de modèles concurrents. Il nous faut donc trouver autre chose.

Précisons que l'absence du module gc et donc de gc.collect() ne signifie absolument pas que le heap ne sera jamais nettoyé. C'est juste que nous ne contrôlons pas le moment où il le sera.

Et bien voici l'élément final du protocole de test que nous te proposons, avec une boucle répétant des appels mem(0), ce qui devrait finir par déclencher des nettoyages du heap, et te signalant à chaque fois que la valeur retournée bat ainsi un nouveau record :

Code: Select all: def testmem(): m1, m2 = 0, 0 while 1: t1, t2 = mem(0) if t1 > m1 or t2 > m2: m1 = max(t1, m1) m2 = max(t2, m2) input(str((m1,m2)))

Sur les TI-83 Premium CE Edition Python et TI-84 Plus CE-T Python Edition, nous pouvons donc exploiter jusqu'à 17,601 Ko de heap.

C'est extrêmement faible, tes projets Python ne pourront pas aller bien loin !

Prenons maintenant l'ancienne TI-83 Premium CE munie du module externe TI-Python interdit aux examens français, mais restant utilisable en classe ainsi qu'aux évaluations si l'enseignant le permet.

Ce n'est pas la panacée mais c'est quand même sensiblement mieux, avec 19,496 Ko. Cela s'explique par l'absence de nombre de modules rajoutés dans le contexte de la TI-83 Premium CE Edition Python, dont les modules de tracé.

Conscient du problème de sous-dimensionnement de ce heap, Lionel Debroux a développé un firmware tiers pour le module externe TI-Python.

Attention, il n'est toutefois utilisable qu'avec des calculatrices en version 5.3.5, Texas Instruments ayant rajouté des protections pour interdire cela depuis.

Si tu l'installes tu bénéficieras donc d'un espace heap disponible nettement amélioré, avec 22,158 Ko.

C'est donc au-delà de la capacité heap de 19,968 Ko trouvée plus haut pour le firmware officiel, mais c'est normal puisque l'on se rend compte que Lionel a en effet passé la capacité heap à 22,912 Ko.

La nouvelle TI-82 Advanced Edition Python de cette rentrée 2021 offre quant à elle 19,700 Ko.

Encore une fois, cette amélioration cache en réalité l'absence de nombre de modules.

Arrive maintenant la NumWorks. Avec le firmware officiel Epsilon, elle nous offre 32,571 Ko de heap.

Nous sommes certes moins à l'étroit que sur les modèles précédents, il y a de quoi commencer à aborder des projets un peu plus gourmands en ressources, mais pas aller très loin non plus.

Sous conditions, tu as la possibilité d'installer très facilement le firmware tiers Omega qui t'offrira pour sa part pas moins de 98,928 Ko de heap !

Attention toutefois, le constructeur a décidé de t'interdire cette possibilité. Si ta machine vient avec une version 16.3+ du firmware officiel Epsilon, ou est mise à jour avec une de ces versions, elle sera verrouillée contre l'installation de firmwares tiers, et ce à notre connaissance à ce jour sans aucun retour possible.

Avec la Casio Graph 35+E II, nous avons enfin d'origine quelque chose de très correct, pas moins de 100,432 Ko de heap !

Il existe aussi une application Python tierce pour les Casio Graph monochromes, CasioPython. Elle est compatible avec les modèles suivants, mais hélas bloquée par le mode examen :

Graph 75+E
Graph 35+E via une installation du système Graph 75+E
Graph 35+E II

Sur les deux premiers nous nous envolons à pas moins de 257,026 Ko !

En effet selon le module gc, la capacité heap a ici été réglée à 258,048 Ko.

Hélas, un bug toujours pas corrigé depuis l'année dernière fait que CasioPython reconnaît bêtement la Graph 35+E II comme un ancien modèle, n'y réservant alors qu'une capacité heap de 32,256 Ko.

Nous n'obtenons alors qu'un espace heap libre de 31,163 Ko, ici donc sans aucun intérêt par rapport à l'application Python officielle.

La Casio Graph 90+E nous met maintenant littéralement en orbite avec un formidable 1032,967 Ko soit 1,033 Mo, de quoi développer des projets absolument fantastiques !

Les TI-Nspire CX II sont encore plus extraordinaires. 2051,137 Ko, soit 2,051 Mo de heap, pour des projets Python absolument formidables !

Sur les TI-Nspire CX, tu peux installer l'application KhiCAS qui intègre un interpréteur Micropython.

Nous avons donc par défaut 1024,540 Ko de heap, soit 1,025 Mo !

KhiCAS intègre de plus son propre mode examen que tu peux activer depuis ses menus. Parfaitement compatible avec celui de Texas Instruments, ce mode examen a le gros avantage de laisser KhiCAS disponible !

Attention toutefois, le mode examen de KhiCAS n'est pas compatible avec les TI-Nspire CX II.

De plus, l'installation de Micropython nécessite Ndless.

À ce jour Ndless n'est pas installable sur les TI-Nspire CX II et TI-Nspire CX munies des dernières mises à jour 5.3.2 ou 4.5.5, et il n'y a aucun moyen de revenir à une version précédente.

En théorie KhiCAS permet de configurer la taille du heap. Cela semblait marcher sur des versions précédentes, mais apparemment ce n'est plus le cas sur les dernières versions. Toute modification même infime de la taille par défaut nous amène très rapidement à des plantages avant même d'avoir réussi à exécuter notre script.

Dommage, pour le moment nous ne pourrons donc pas en tenir compte cette année.

Les TI-Nspire CM et TI-Nspire monochromes n'ont que 32 Mio de mémoire SDRAM, ce qui n'est pas suffisant pour KhiCAS. À la place on peut prendre Micropython qui nous fait littéralement quitter l'attraction terrestre avec pas moins de 2049,201 Ko soit 2,049 Mo !

En creusant un petit peu grâce au module gc ici disponible, nous découvrons que la capacité heap est de 2,049 Mo.

Attention, l'installation de Micropython nécessite Ndless.

À ce jour Ndless n'est pas installable sur les TI-Nspire CX II et TI-Nspire CX munies des dernières mises à jour 5.3.2 ou 4.5.5, et il n'y a aucun moyen de revenir à une version précédente.

De plus, Micropython disparaîtra en mode examen.

Et enfin il y a la HP Prime. Ah la HP Prime... ici nous ne sommes plus en orbite mais déjà dans une galaxie lointaine, très lointaine...

Distinguons les HP Prime G1 avec 32 Mio de SDRAM, et HP Prime G2 avec 256 Mio de SDRAM, testées toutes deux juste après un reset :

La HP Prime G1 offre 1020,293 Ko de heap, soit 1,020 Mo
La HP Prime G2 offre 1023,804 Ko de heap, soit 1,024 Mo

Par contre, la capacité du heap est ici réglable via

Shift

Plot

.

Sur pas moins de 3 HP Prime G1, on arrive à régler très exactement jusqu'à 16127 Ko avant plantage.
Sur HP Prime G2, on arrive à régler à peine davantage, jusqu'à 16384 Ko, un bug nous interdisant de régler des valeurs supérieures via cette boîte de dialogue.

Mais ne nous avouons pas encore vaincus. Les HP Prime permettent d'exécuter des scripts et fonctions Python depuis l'éditeur de programmes historique grâce à la fonction PYTHON(). Or, il se trouve que cette fonction permet de spécifier la capacité heap à allouer : PYTHON({nom_python,taille_heap},...).

Réalisons de quoi saisir et tester des capacités :

Code: Select all: #python heaptest_python from gc import mem_alloc,mem_free a,f=mem_alloc(),mem_free() print("allocated heap: "+str(f+a)) print("free heap: "+str(f)) #end Export heaptest_ppl(v) Begin PRINT("allocating heap: "+v); PRINT(""); PYTHON({heaptest_python,v}); End;

La HP Prime G2 nous permet ainsi de spécifier jusqu'à 258 Mo et quelques, en pratique restons sur 258 Mo.

La capacité heap alors réellement reportée par le module gc est d'environ 252,1 Mo !

Les mesures sont facilement comparables sur le lien ci-dessous, et même disponibles pour bien d'autres modèles plus anciens :

Accès QCC 2021 Universel

en exam
officiel en exam
tiers hors exam
officiel hors exam
tiers

252,1 Mo : HP Prime G2
15,6 Mo : HP Prime G1
2,051 Mo : TI-Nspire CX II
1,033 Mo : Casio Graph 90+E
100,432 Ko : Casio Graph 35+E II
32,571 Ko : NumWorks
19,700 Ko : TI-82 Advanced Edition Python
17,601 Ko : TI-83 Premium CE Edition Python

252,1 Mo : HP Prime G2
15,6 Mo : HP Prime G1
2,051 Mo : TI-Nspire CX II
1,033 Mo : Casio Graph 90+E
1,025 Mo : TI-Nspire CX (Ndless + KhiCAS)
100,432 Ko : Casio Graph 35+E II
98,928 Ko : NumWorks (firmware Omega)
64,954 Ko : NumWorks N0110 (firmware Delta / Omega + appli KhiCAS)
32,571 Ko : NumWorks
25,235 Ko : NumWorks N0110 (firmware Delta)
19,700 Ko : TI-82 Advanced Edition Python
17,601 Ko : TI-83 Premium CE Edition Python

252,1 Mo : HP Prime G2
15,6 Mo : HP Prime G1
2,051 Mo : TI-Nspire CX II
1,033 Mo : Casio Graph 90+E / fx-CG50
100,432 Ko : Casio Graph 35+E II / fx-9750/9860GIII
32,571 Ko : NumWorks
19,496 Ko : TI-83 Premium CE + TI-Python
19,700 Ko : TI-82 Advanced Edition Python
17,601 Ko : TI-83 Premium CE Edition Python / TI-84 Plus CE Python Edition

252,1 Mo : HP Prime G2
15,6 Mo : HP Prime G1
2,051 Mo : TI-Nspire CX II
2,049 Mo : TI-Nspire (Ndless + MicroPython)
1,033 Mo : Casio Graph 90+E / fx-CG50
1,025 Mo : TI-Nspire CX / CX II (Ndless + KhiCAS CX / KhiCAS CX II)
257,026 Ko : Casio Graph 35/75+E / 35/75/95 / fx-9750/9860GII (SH4 - appli CasioPython)
100,432 Ko : Casio Graph 35+E II / fx-9750/9860GIII
98,928 Ko : NumWorks (firmware Omega)
64,954 Ko : NumWorks N0110 (firmware Omega + appli KhiCAS)
32,571 Ko : NumWorks
32,256 Ko : Casio Graph 35+E II / 35/75/85/95(SH3) / fx-9750/9860GIII / fx-9750/9860GII(SH3) / fx-9860G (appli CasioPython)
25,235 Ko : NumWorks N0110 (firmware Delta)
22,158 Ko : TI-83 Premium CE + TI-Python (firmware tiers)
19,496 Ko : TI-83 Premium CE + TI-Python
19,700 Ko : TI-82 Advanced Edition Python
17,601 Ko : TI-83 Premium CE Edition Python / TI-84 Plus CE Python Edition

by **critor** » 17 Aug 2021, 20:15

Quelle Calculatrice Choisir 2021 édition Universelle

Épisode 6 - Python zone graphique utile

Pour fêter les 10 ans de TI-Planet en cette rentrée 2021, nous te publions la base de données intégrale de nos classements de rentrée QCC organisés depuis la rentrée 2015.

Nous en profitons de plus pour te réaliser le travail titanesque d'étendre les tests aux modèles plus anciens :

toutes les calculatrices graphiques Texas Instruments (depuis la première TI-81 de 1990)
toutes les calculatrices graphiques Casio à technologie Flash (depuis 2003)

Ce qui donne pas moins de 132 modèles différents de calculatrices testés sous toutes leurs coutures, 10 ans de tests et découvertes à portée de clic !

Dans un épisode précédent, nous t'avons révélé les dimensions de la zone graphique utile de chaque modèle, c'est-à-dire la zone dont l'utilisateur peut librement allumer les pixels :

par tracé de graphes
par exécution de programmes en langage constructeur/historique (très souvent un langage Basic)

Nous avions volontairement laissé de côté les scripts Python que nous allons donc traiter séparément aujourd'hui. En effet la zone graphique contrôlable par les scripts Python a bien souvent des dimensions différentes.

Comment donc faire maintenant pour tester la taille de la zone graphique, rien qu'en lisant / écrivant des pixels ? Et bien c'est très simple, tu ne vas pas être dépaysé(e).

Nous allons procéder comme avec une tortue (langage Scratch ou module Python turtle). Nous allons parcourir l'écran, en diagonale, en tentant de lire et modifier chaque pixel rencontré.

Pour savoir si un pixel est accessible en écriture, nous tenterons d'inverser sa couleur :

Code: Select all: def invert_color(c): try: ci = [0, 0, 0] for k in range(3): ci[k] = 255 - c[k] except: ci = ~(c&0xffffff) & 0xffffff return ci def is_pixel_writable(x, y, bad_pixel): if is_pixel_readable(x, y, bad_pixel): c0 = get_pixel(x, y) set_pixel(x, y, invert_color(c0)) c = get_pixel(x, y) return c != c0

Pour savoir si un pixel que l'on arrive à lire correspond bien à un pixel visible de l'écran, nous prendrons comme référence la mauvaise valeur de pixel retournée par une lecture clairement hors écran, coordonnées (-2, -2).
Dans le seul cas où l'on rencontre cette valeur qui peut très bien être justifiée, nous tenterons ici encore de l'inverser.

Code: Select all: def is_pixel_readable(x, y, bad_pixel): c = None try: c = get_pixel(x, y) except: pass if c != None: if c == bad_pixel: set_pixel(x, y, invert_color(c)) c = get_pixel(x, y) return c != bad_pixel

Voici donc les fonctions principales utilisant tout ça :

Code: Select all: def scr_test(x0, y0, dx0, dy0, test): bad_pixel = None try: bad_pixel = get_pixel(-2, -2) except: pass x, y, dx, dy = x0, y0, dx0, dy0 while not test(x, y, bad_pixel): x += dx y += dy if test(x, y - dy, bad_pixel): y = y0 elif test(x - dx, y, bad_pixel): x = x0 x0, y0 = x, y x += dx y += dy while(dx or dy): if not test(x - ((dx == 0) and dx0),y - ((dy == 0) and dy0), bad_pixel): if test(x - ((dx == 0) and dx0), y - ((dy == 0) and dy0) - dy0, bad_pixel): dy = 0 elif test(x - ((dx == 0) and dx0) - dx0, y - ((dy == 0) and dy0), bad_pixel): dx = 0 else: dx, dy = 0, 0 x += dx y += dy return x0, y0, (x - x0) // dx0, (y - y0) // dy0 def scr_size(): xrd0, yrd0, xrd, yrd = scr_test(0, 0, -1, -1, is_pixel_readable) xra0, yra0, xra, yra = scr_test(1, 1, 1, 1, is_pixel_readable) xr0, yr0 = xrd0 - xrd + 1, yrd0 - yrd + 1 xr, yr = xra + xrd, yra + yrd xw0, yw0, xw, yw = scr_test(xr0, yr0, 1, 1, is_pixel_writable) print("at (" + str(xr0) + "," + str(yr0) + "): " + str(xr) + "x" + str(yr) + " readable pixels") print("at (" + str(xw0) + "," + str(yw0) + "): " + str(xw) + "x" + str(yw) + " writable pixels") return xr0, yr0, xr, yr, xw0, yw0, xw, yw

Il suffit donc d'appeler scr_size(), et tu vas vite comprendre avec notre premier exemple.

Les TI-83 Premium CE Edition Python et TI-84 Plus CE-T Python Edition t'offrent donc un écran 320×240 pixels, et une zone utile pour graphes et programmes de 265×165 pixels (56,93%).

En Python, les fonctions relatives aux pixels sont ti_graphic.getPixel(x, y) et ti_graphic.setPixel(x, y, couleur).

Après donc parcours de l'écran en diagonale par notre tortue virtuelle, cette dernière nous reporte :

321×241= 77361 pixels pouvant être lus à partir des coordonnées (-1, -1)
321×210= 67410 pixels pouvant être écrits à partir des coordonnées (-1, 30)

Si le fonctionnement est simple, plusieurs bizarreries dans le résultat sont toutefois à traiter ici.

Déjà sur les deux zones différentes qui nous sont retournées :

la première signifie que l'on peut lire l'intégralité des pixels de l'écran
la deuxième ne retient donc plus que les pixels pouvant être modifiés, ici situés en-dessous de la barre d'état de 30 pixels de hauteur, et c'est celle-ci qui correspond à la zone graphique, la seule zone où la tortue a réussi à tracer son chemin comme tu vois ci-contre

Ensuite, selon notre tortue nous aurions donc un écran de 321×241 pixels, soit plus que les 320×240 pixels précédemment annoncés, avec :

une ligne de pixels d'ordonnée -1 pouvant être lus
une colonne de pixels d'abscisse -1 pouvant être lus, et également écrits à partir de l'ordonnée 30 marque le début de la zone graphique précédente

Or une tentative d'écriture donc sur cette dernière colonne ne donne visiblement rien à l'écran.

Soit il y a un bug dans notre code expliquant ce résultat différent de la réalité, et tu verras bien ci-dessous si la même anomalie est présente sur d'autres modèles ou pas avec exactement le même code.

Soit la chose vient de Texas Instruments. Nous aurions donc un écran de 320×240 pixels, mais avec en mémoire un buffer associé de 321×241 pixels. Ou bien c'est un bug, ou bien il y a une raison technique que nous ignorons à ce jour pour disposer en mémoire d'1 ligne et d'1 colonne supplémentaires de pixels sans aucune existence physique.

Pour notre classement, nous retiendrons donc ici une zone graphique correspondant à la réalité, c'est-à-dire de 320×210, soit 87,50% de la définition de l'écran, c'est déjà bien mieux qu'avec le langage historique !

La Casio Graph 90+E t'offre un écran de 396×224 pixels, avec une zone utile pour graphes et programmes de 379×187 pixels (79,90%).

En Python, les fonctions relatives aux pixels sont casioplot.get_pixel(x, y) et casioplot.set_pixel(x, y, couleur).

Mais voyons maintenant ce que cela donne dans l'application Python.

Et c'est fantastique, Casio ici aussi a fait un effort, ce sont pas moins de 384×192 pixels qui sont contrôlables en Python, soit 83,12% de l'écran !

Sur les modèles précédents Casio fx-CG10 et fx-CG20, pas de mise à jour avec Python.

Toutefois tu as également la possibilité d'installer l'application KhiCAS, une adaptation pour ta calculatrice du logiciel de mathématiques intégré Xcas par Bernard Parisse, enseignant-chercheur à l'Université de Grenoble.

L'environnement est également programmable avec une syntaxe proche du Python. Pas de fonctions pour contrôler individuellement les pixels ici, mais par contre nous y disposons d'une tortue dont on peut spécifier les déplacements en pixels. Tentons de tracer un rectangle le plus grand possible à l'aide du code suivant :

Code: Select all: def scrtest(w, h): efface leve_crayon tourne_gauche 180 avance w // 3 tourne_gauche 90 avance h // 2 baisse_crayon for k in range(2): tourne_gauche 90 avance w tourne_gauche 90 avance h

C'est l'appel scrtest(383, 191) qui nous permet de rentrer le plus grand rectangle possible dans l'écran. Comme les paramètres concernent ici des déplacements de la tortue cela correspond à une zone graphique de 384×192 (83,12%), soit exactement comme avec l'application Python officielle.

La Casio Graph 35+E II dispose d'un écran de 128×64 pixels, avec une zone utile pour graphes et programmes de 127×63 pixels (97,67%).

En Python, les fonctions relatives aux pixels sont ici encore casioplot.get_pixel(x, y) et casioplot.set_pixel(x, y, couleur).

Et en Python c'est donc superbe, nous contrôlons apparemment 128×64 pixels soit 100% de l'écran.

Les TI-Nspire CX II utilisent un écran 320×240 pixels, avec une zone utile pour graphes et programmes de 318×212 pixels (87,78%).

Le module Python de tracé par pixels est ti_draw. Il ne dispose pas de fonction permettant d'allumer un pixel isolé comme un set_pixel(). On pourrait certainement remplacer cela par un appel draw_rect(x, y, 0, 0) pour tracer un rectangle d'1 pixel de surface. Mais surtout, ti_draw ne dispose pas de fonction get_pixel().

En fait, get_pixel() et set_pixel() sont offertes dans le cadre d'une autre module ti_image, permettant de travailler sur un calque avant de l'afficher. Mais comme il faut définir les dimensions du calque en question, un test basé là-dessus ne serait pas pertinent.

Toutefois, ti_draw fournit une fonction get_screen_dim() nous permettant de récupérer les dimensions de la zone graphique utilisable, sans surprise ici les mêmes 318×212 pixels.

Sur les anciennes TI-Nspire CX, pas de mise à jour avec Python.

Toutefois, si ta calculatrice n'a pas été mise à jour avec la dernière version 4.5.5, tu peux installer Ndless et ensuite l'application KhiCAS.

KhiCAS intègre un interpréteur Python et surtout un mode examen compatible avec celui de Texas Instruments. Si tu actives le mode examen depuis les menus de KhiCAS, ce dernier restera disponible en mode examen !

Les fonctions get_pixel() et set_pixel() sont ici offertes via le module graphic. Ce module est également accessible via les alias casioplot et kandinsky, ce qui permet une compatibilité directe avec les scripts conçus pour Casio et NumWorks !

Notre script de test détecte ici 320×222 pixels pouvant à la fois être lus et écrits, soit 92,5%.

Sur les TI-Nspire CM et TI-Nspire monochromes, nous n'avons pas que 32 Mio de SDRAM au lieu de 64 Mio. Ce n'est pas suffisant pour lancer KhiCAS.

Tu peux ici installer Ndless puis ensuite l'application MicroPython.

On y contrôle alors 320×240 pixels soit 100% de l'écran !

Attention toutefois, l'activation du mode examen t'interdira l'usage de cette application.

La NumWorks t'apporte un écran de 320×240 pixels, dont comme nous avons vu 320×204 pixels pour les graphes (85%).

En Python, les fonctions qui nous intéressent ici sont kandinsky.get_pixel(x, y) et kandinsky.set_pixel(x, y, couleur).

Nous avons donc accès ici à une zone graphique de 320×222 pixels, soit 92,5% !

La HP Prime t'offre un écran de 320×240 pixels, intégralement utilisables par les graphes et programmes en langage constructeur (HPPPL).

Le module Python hpprime nous offre de quoi écrire un pixel : pixon(numero_calque, x, y, couleur).

Il ne fournit pas directement de quoi lire un pixel, mais par contre une fonction eval() permettant de faire appel au langage constructeur HPPPL où cette fonction existe. On peut alors se redéfinir une fonction get_pixel() en Python :

Code: Select all: def get_pixel(x, y): return int(eval("get_pixel(" + str(x) + "," + str(y) + ")"))

Sans surprise ici aussi, nous contrôlons les mêmes 320×240 pixels soit 100% de l'écran !

Les mesures sont toutes disponibles et facilement comparables sur le lien ci-dessous :

Accès QCC 2021 Universel

by **critor** » 19 Aug 2021, 14:09

Quelle Calculatrice Choisir 2021 édition Universelle

Épisode 7 - Performances générales

Pour fêter les 10 ans de TI-Planet en cette rentrée 2021, nous te publions la base de données intégrale de nos classements de rentrée QCC organisés depuis la rentrée 2015.

Nous en profitons de plus pour te réaliser le travail titanesque d'étendre les tests aux modèles plus anciens :

toutes les calculatrices graphiques Texas Instruments (depuis la première TI-81 de 1990)
toutes les calculatrices graphiques Casio à technologie Flash (depuis 2003)

Ce qui donne pas moins de 136 modèles différents de calculatrices testés sous toutes leurs coutures, 10 ans de tests et découvertes à portée de clic !

Aujourd'hui, commençons à parler performances.

Nous effectuerons jusqu'à 2 tests, lorsque possible, et chronométrerons leur durée :

un test avec un gros calcul
un test avec un programme

Le test avec le programme ne concernera pour le moment que les langages constructeur/historiques, pas le Python. En effet sur nombre de modèles l'application en question ne bénéficie pas d'une intégration à l'environnement de la calculatrice, mais tourne à part dans son coin, souvent sans pouvoir échanger/partager de données. Elle n'est donc pas représentative des performances générales du logiciel de la calculatrice.

Pour les modèles disposant d'un moteur de calcul exact, littéral ou même formel (CAS), les deux tests seront effectués en mode de calcul décimal.

Certains modèles comme les Lexibook GC3000FR et Esquisse GCEXFR sont tellement limités en capacités qu'ils ne remplissent même pas les conditions pour passer un seul de ces deux tests.

Commençons par le test de performances via un calcul. Pour les modèles disposant de l'opérateur de sommation, nous retenons le calcul développé par pier4r sur HP Museum, en mode degrés :

$mathjax$\sum\limits_{x=1}^{1000}{\sqrt[3]{e^{sin\left(Arctan\left(x\right)\right)}}}$mathjax$

Pour les modèles plus puissants terminant le calcul parfois avant même que l'on ait le temps de relâcher la dernière touche, la borne supérieure de la somme sera augmentée, et le temps mesuré corrigé en conséquence par proportionnalité.

Pour la fx-92+ Spéciale Collège qui ne dispose pas de l'opérateur de sommation, nous testerons à la place le modèle haut de gamme allemand fx-991DE X utilisant exactement le même matériel.

Voici dès maintenant le classement des modèles selon leurs performances sur ce calcul :

sans
overclock avec
overclock

0,130s : HP Prime G2 (32 bits : Cortex-A7/ARMv7 @528MHz)
0,448s : HP Prime G1 (32 bits : ARM9/ARMv5 @400MHz)
0,997s : TI-Nspire CX II (32 bits : ARM9/ARMv5 @396MHz)
1,481s : NumWorks N0110 (32 bits : Cortex-M7/ARMv7 @216MHz)
2,069s : NumWorks N0100 (32 bits : Cortex-M4/ARMv7 @100MHz)
2,119s : TI-Nspire (32 bits : ARM9/ARMv5 @120MHz)
2,256s : TI-Nspire CX (révisions W+) (32 bits : ARM9/ARMv5 @156MHz)
2,604s : TI-Nspire CX (révisions ≤V) (32 bits : ARM9/ARMv5 @132MHz)
6,330s : Casio fx-CP400 (32 bits : SH4 @117,96MHz)
8,550s : Casio Graph 90+E (32 bits : SH4 @117,96MHz)
13,15s : TI-84 Plus CE-T Python Edition / TI-84 Plus CE-T (révisions M+) (8 bits : eZ80 @48MHz)
13,59s : Casio Graph 25+E II (32 bits : SH4 @58,98MHz)
13,76s : TI-82 Advanced Edition Python (8 bits : eZ80 @48MHz)
14,11s : Casio Graph 35+E II (32 bits : SH4 @58,98MHz)
14,11s : TI-83 Premium CE Edition Python (8 bits : eZ80 @48MHz)
20,11s : Casio Graph 25+E (32 bits : SH4 @29,49MHz)
23,05s : Casio Graph 35/75+E (32 bits : SH4 @29,49MHz)
36,05s : TI-84 Plus CE-T (révisions ≤L) (8 bits : eZ80 @48MHz)
36,99s : TI-83 Premium CE (8 bits : eZ80 @48MHz)
52,79s : TI-84 Plus T (8 bits : z80 @15MHz)
56,25s : TI-82 Advanced (8 bits : z80 @15MHz)
108,6s : Casio fx-92+ Spéciale Collège (8 bits : nX-U8/100 @?MHz)

0,130s : HP Prime G2 (32 bits : Cortex-A7/ARMv7 @528MHz)
0,448s : HP Prime G1 (32 bits : ARM9/ARMv5 @400MHz)
0,609s : TI-Nspire CX II (32 bits : ARM9/ARMv5 ~~396MHz~~ overclocké @480MHz NoverII)
1,481s : NumWorks N0110 (32 bits : Cortex-M7/ARMv7 @216MHz)
1,571s : TI-Nspire (32 bits : ARM9/ARMv5 ~~@120MHz~~ overclocké @150MHz Nover)
1,857s : TI-Nspire CX (révisions ≤V) (32 bits : ARM9/ARMv5 ~~@132MHz~~ overclocké @222MHz Nover)
1,992s : TI-Nspire CX (révisions W+) (32 bits : ARM9/ARMv5 ~~@156MHz~~ overclocké @216MHz Nover)
2,069s : NumWorks N0100 (32 bits : Cortex-M4/ARMv7 @100MHz)
3,220s : Casio Graph 35/75+E (32 bits : SH4 ~~@29,49MHz~~ overclocké @267,78MHz Ftune2)
4,320s : Casio Graph 35+E II (32 bits : SH4 ~~@58,98MHz~~ overclocké @274,91MHz Ftune3)
5,240s : Casio Graph 90+E (32 bits : SH4 ~~@117,96MHz~~ overclocké @270,77MHz Ptune3)
6,330s : Casio fx-CP400 (32 bits : SH4 @117,96MHz)
13,15s : TI-84 Plus CE-T Python Edition / TI-84 Plus CE-T (révisions M+) (8 bits : eZ80 @48MHz)
13,59s : Casio Graph 25+E II (32 bits : SH4 @58,98MHz)
13,76s : TI-82 Advanced Edition Python (8 bits : eZ80 @48MHz)
14,11s : TI-83 Premium CE Edition Python (8 bits : eZ80 @48MHz)
20,11s : Casio Graph 25+E (32 bits : SH4 @29,49MHz)
26,75s : TI-84 Plus CE-T (révisions ≤L) (8 bits : eZ80 @48MHz accéléré AWSC)
31,97s : TI-83 Premium CE (8 bits : eZ80 @48MHz accéléré AWSC)
52,79s : TI-84 Plus T (8 bits : z80 @15MHz)
56,25s : TI-82 Advanced (8 bits : z80 @15MHz)
108,6s : Casio fx-92+ Spéciale Collège (8 bits : nX-U8/100 @?MHz)

Maintenant sur les modèles programmables, nous allons programmer un algorithme de seuil sur une suite numérique, niveau Première, programme que nous te transcrivons ici en Python à des fins de lisibilité :

Code: Select all: def seuil(d): n = 0 u = 2. d = d**2 while (u-1)**2 >= d: u = 1 + 1/((1-u) * (n+1)) n = n + 1 return [n, u]

Nous appellerons seuil(0.008).

Mais comme dit plus haut, ce code sera donc transcrit ligne à ligne dans le langage de programmation historique de chaque constructeur, bien souvent du Basic.

Et voilà le classement des modèles selon leurs performances sur le programme de seuil :

sans
overclock avec
overclock

0,690s : HP Prime G2 (32 bits : Cortex-A7/ARMv7 @528MHz)
2,410s : HP Prime G1 (32 bits : ARM9/ARMv5 @400MHz)
8,930s : TI-Nspire CX II (32 bits : ARM9/ARMv5 @396MHz)
12,24s : TI-Nspire (32 bits : ARM9/ARMv5 @120MHz)
18,94s : TI-Nspire CX (révisions W+) (32 bits : ARM9/ARMv5 @156MHz)
20,92s : TI-Nspire CX (révisions ≤V) (32 bits : ARM9/ARMv5 @132MHz)
50,77s : Casio Graph 90+E (32 bits : SH4 @117,96MHz)
73,50s : Casio Graph 25+E II (32 bits : SH4 @58,98MHz)
81,03s : Casio Graph 35+E II (32 bits : SH4 @58,98MHz)
93,19s : TI-82 Advanced Edition Python (8 bits : eZ80 @48MHz)
94,26s : TI-84 Plus CE-T Python Edition / TI-84 Plus CE-T (révisions M+) (8 bits : eZ80 @48MHz)
98,64s : TI-83 Premium CE Edition Python (8 bits : eZ80 @48MHz)
101,1s : Casio Graph 35/75+E (32 bits : SH4 @29,49MHz)
119,6s : Casio Graph 25+E (32 bits : SH4 @29,49MHz)
194,4s : TI-84 Plus CE-T (révisions ≤L) (8 bits : eZ80 @48MHz)
196,8s : TI-83 Premium CE (8 bits : eZ80 @48MHz)
255,9s : TI-84 Plus T (8 bits : z80 @15MHz)
260,4s : TI-82 Advanced (8 bits : z80 @15MHz)
607.9s : Casio fx-CP400 (32 bits : SH4 @117,96MHz)
672,7s : Casio fx-92+ Spéciale Collège (8 bits : nX-U8/100 @?MHz)

0,690s : HP Prime G2 (32 bits : Cortex-A7/ARMv7 @528MHz)
2,410s : HP Prime G1 (32 bits : ARM9/ARMv5 @400MHz)
7,690s : TI-Nspire CX II (32 bits : ARM9/ARMv5 ~~396MHz~~ overclocké @480MHz NoverII)
10,02s : TI-Nspire (32 bits : ARM9/ARMv5 ~~@120MHz~~ overclocké @150MHz Nover)
18,64s : TI-Nspire CX (révisions W+) (32 bits : ARM9/ARMv5 ~~@156MHz~~ overclocké @216MHz Nover)
19,56s : TI-Nspire CX (révisions ≤V) (32 bits : ARM9/ARMv5 ~~@132MHz~~ overclocké @222MHz Nover)
23,26s : Casio Graph 35/75+E (32 bits : SH4 ~~@29,49MHz~~ overclocké @267,78MHz Ftune2)
26,36s : Casio Graph 35+E II (32 bits : SH4 ~~@58,98MHz~~ overclocké @274,91MHz Ftune3)
38,33s : Casio Graph 90+E (32 bits : SH4 ~~@117,96MHz~~ overclocké @270,77MHz Ptune3)
73,50s : Casio Graph 25+E II (32 bits : SH4 @58,98MHz)
93,19s : TI-82 Advanced Edition Python (8 bits : eZ80 @48MHz)
94,26s : TI-84 Plus CE-T Python Edition / TI-84 Plus CE-T (révisions M+) (8 bits : eZ80 @48MHz)
98,64s : TI-83 Premium CE Edition Python (8 bits : eZ80 @48MHz)
119,6s : Casio Graph 25+E (32 bits : SH4 @29,49MHz)
169,5s : TI-84 Plus CE-T (révisions ≤L) (8 bits : eZ80 @48MHz accéléré AWSC)
171,3s : TI-83 Premium CE (8 bits : eZ80 @48MHz accéléré AWSC)
255,9s : TI-84 Plus T (8 bits : z80 @15MHz)
260,4s : TI-82 Advanced (8 bits : z80 @15MHz)
607.9s : Casio fx-CP400 (32 bits : SH4 @117,96MHz)
672,7s : Casio fx-92+ Spéciale Collège (8 bits : nX-U8/100 @?MHz)

Deux indices de performances représentant chacun de ces deux tests sont dès maintenant disponibles, également pour les modèles plus anciens que nous avions encore sous la main :

Accès QCC 2021 Universel

by **critor** » 20 Aug 2021, 12:45

Quelle Calculatrice Choisir 2021 édition Universelle

Épisode 8 - Écrans et profondeurs

Pour fêter les 10 ans de TI-Planet en cette rentrée 2021, nous te publions la base de données intégrale de nos classements de rentrée QCC organisés depuis la rentrée 2015.

Nous en profitons de plus pour te réaliser le travail titanesque d'étendre les tests aux modèles plus anciens :

toutes les calculatrices graphiques Texas Instruments (depuis la première TI-81 de 1990)
toutes les calculatrices graphiques Casio à technologie Flash (depuis 2003)

Ce qui donne pas moins de 136 modèles différents de calculatrices testés sous toutes leurs coutures, 10 ans de tests et découvertes à portée de clic !

L'écran est décidément un élément incontournable de ta calculatrice graphique. Après avoir couvert dans des épisodes précédents ses dimensions, définition et zone graphique, nous allons aujourd'hui traiter de sa profondeur, c'est-à-dire du nombre de couleurs différentes qu'il permet d'afficher.

Commençons par enfoncer les portes ouvertes, avec les modèles dont le contrôleur écran ne gère que 1 bit de profondeur, ne permettant donc que 2¹= 2 couleurs différentes.

D'une part, voici les modèles à cristaux liquides bleus souffrant en conséquence d'une lisibilité assez pénible sans un excellent éclairage extérieur :

Esquisse GCEXFR
Lexibook GC3000FR
Casio Graph 25+E

Et voici les modèles à cristaux liquides noirs, de bien meilleure lisibilité :

Casio Graph 25+E II
Casio Graph 35+E
Casio Graph 35+E II
Casio Graph 75+E
TI-82 Advanced
TI-84 Plus T
Casio fx-92+ Spéciale Collège

Passons maintenant aux choses intéressantes ; nous allons te présenter notre protocole de test.

Notre idée est donc d'afficher une mire avec des dégradés des composantes primaires rouge-vert-bleu, afin de déterminer le nombre de bits utilisés par chacune.

Il y a 2 façons de coder les couleurs dans le contexte des pixels en Python :

soit avec un tuple (r,g,b) décrivant les valeurs de chaque composante primaire rouge-vert-bleu par un entier de 0 à 255
soit par un nombre entier qui sera directement la valeur fournie au contrôleur écran

Prévoyons une fonction pour tester le codage utilisé, par simple vérification du type de retour d'une lecture de pixel.
Dans le cas d'un retour de type entier, tentons de plus en passant de détecter le nombre de bits gérés par le contrôleur écran, en écrivant des valeurs de pixels de plus en plus grandes et vérifiant à chaque fois si le pixel concerné a bien pris la valeur en question.

Code: Select all: #0: (R,G,B) >0: RGB-bits def get_color_mode(): c = get_pixel(0, 0) try: c[2] return 0 except: b, v = 0, 1 x, y = 0, sy0 set_pixel(x, y, v) while get_pixel(x, y) == v: b += 1 v *= 2 set_pixel(x, y, v) return b

Un appel color_mode = get_color_mode() pourra donc renvoyer par exemple :

0 : pour un codage des couleurs par des tuples (r,g,b)
15 : pour un codage des couleurs sur des entiers de 15 bits
16 : pour un codage des couleurs sur des entiers de 16 bits
24 : pour un codage des couleurs sur des entiers de 24 bits
...

Pour notre script universel il faudra bien choisir un codage plutôt qu'un autre, alors prévoyons une fonction de conversion :

Code: Select all: def fixcolor(c, bits=16): try: if not color_mode: return c r, g, b = c[0], c[1], c[2] except: if color_mode == bits: return c if bits == 16: br, bg, bb = 5, 6, 5 else: br, bg, bb = 8, 8, 8 r, g, b = c & (2**br - 1) * 2**(8 - br), c & ((2**bg - 1) * 2**br) // 2**br * 2**(8 - bg), c & ((2**bb - 1) * 2**(br + bg)) // 2**(br + bg) * 2**(8 - bb) if not color_mode: return (r, g, b) else: if color_mode == 16: br, bg, bb = 5, 6, 5 else: br, bg, bb = 8, 8, 8 r, g, b = r // 2**(8 - br), g // 2**(8 - bg) * 2**br, b // 2 **(8 - bb) * 2**(br + bg) c = r + g - (r & g) return c + b - (c & b)

Voici de quoi tracer des lignes verticales et horizontales :

Code: Select all: def draw_vline(x, y1, y2, c): for j in range(y2 - y1 + 1): set_pixel(x, y1 + j, c) def draw_hline(y, x1, x2, c): for j in range(x2 - x1 + 1): set_pixel(x1 + j, y, c)

Et voici enfin notre code de tracé de la mire :

Code: Select all: #o: 0=horizontal, 1=vertical #s: 0=no_shadow, 1=shadow left/up, -1=shadow right/down def mire(w, h, y0=0, s=1, o=0): if o: l1, l2, f, i1, i2 = h, w, draw_hline, y0, 0 else: l1, l2, f, i1, i2 = w, h, draw_vline, 0, y0 n = 8 for m in range(l1): v = 255 if s != 0: v = v * (s*m % l1) // (l1 - 1) for j in range(n): f(m + i1, j * l2 // n + i2, (j + 1) * l2 // n - 1 + i2, fixcolor(color8(j, v))) def color8(j, v): c = [0, 0, 0] for b in range(3): if j & 2**b: c[b] = v return c

Tu vas vite comprendre tout ça avec notre premier exemple.

Commençons donc par les TI-83 Premium CE Edition Python et TI-84 Plus CE-T Python Edition que nous allons tester en Python.
Nous considérerons que c'est pareil sur les anciennes TI-83 Premium CE et TI-84 Plus CE, ainsi que sur la nouvelle TI-82 Advanced Edition Python.

Ici les fonctions relatives aux pixels sont ti_graphic.getPixel(x,y) et ti_graphic.setPixel(x,y,couleur). Nous disposons comme déjà vu d'une zone graphique utile en Python de 320×210 pixels, accessibles à partir de y=30.

Cela ne t'apprendra sans doute rien mais histoire de vérifier que ça marche, d'après get_color_mode() sur TI-83 Premium CE Edition Python et TI-84 Plus CE Python Edition les couleurs de pixels sont codées en Python par des tuples (r,g,b).

Voici donc ci-contre l'affichage de l'appel associé mire(320,240,30). On peut noter que le vert ainsi que les couleurs composées de vert (cyan, jaune et blanc) ont un dégradé beaucoup moins saccadé, beaucoup plus fluide. En effet si tu regardes bien elles utilisent 2 fois plus de teintes intermédiaires, très exactement 64 teintes contre 32 pour les autres :

canal rouge sur 5 bits pour 2⁵= 32 teintes
canal vert sur 6 bits pour 2⁶= 64 teintes
canal bleu sur 5 bits pour 2⁵= 32 teintes

Total donc 16 bits pour 2¹⁶= 65536 couleurs affichables, et un contrôleur écran fonctionnant donc au format RGB 565.

Voici maintenant la Casio Graph 90+E et son superbe écran.

Les fonctions relatives aux pixels à utiliser sont casioplot.get_pixel(x,y) et casioplot.set_pixel(x,y,couleur). Nous disposons comme déjà vu en Python d'une zone graphique utile de 384×192 pixels.

Ici encore les paramètres de couleur sont passés sous forme de tuples (r,g,b).

Appelons donc mire(384,192). Même constat ici, nous notons 2 fois plus de teintes intermédiaires pour les dégradés de vert et de couleurs incluant du vert :

canal rouge sur 5 bits pour 2⁵= 32 teintes
canal vert sur 6 bits pour 2⁶= 64 teintes
canal bleu sur 5 bits pour 2⁵= 32 teintes

Total donc 16 bits pour 2¹⁶= 65536 couleurs affichables, et un contrôleur écran fonctionnant donc au format RGB 565.

Arrive maintenant la NumWorks.

Les fonctions de pixels sont kandinsky.get_pixel(x,y) et kandinsky.set_pixel(x,y,couleur). Avec l'application Python officielle, les paramètres de couleur prennent toujours la forme de tuples (r,g,b). La zone graphique utile en Python est ici de 320×222 pixels.

Appelons mire(320,222). Encore pareil, 2 fois plus de teintes intermédiaires dans le vert :

canal rouge sur 5 bits pour 2⁵= 32 teintes
canal vert sur 6 bits pour 2⁶= 64 teintes
canal bleu sur 5 bits pour 2⁵= 32 teintes

Total donc 16 bits pour 2¹⁶= 65536 couleurs affichables, et un contrôleur écran fonctionnant donc au format RGB 565.

Passons donc aux TI-Nspire CX II testables en Python.
Nous considérerons le résultat représentatif des anciennes TI-Nspire CX et TI-Nspire CM.

Les fonctions relatives aux pixels à utiliser sont ti_image.get_pixel(x,y) et ti_image.set_pixel(x,y,couleur). Nous disposons comme déjà vu en Python d'une zone graphique utile de 318×212 pixels.

Ici encore les paramètres de couleur sont passés sous forme de tuples (r,g,b).

Appelons donc mire(318,212). Toujours 2 fois plus de teintes intermédiaires tirant sur le vert :

canal rouge sur 5 bits pour 2⁵= 32 teintes
canal vert sur 6 bits pour 2⁶= 64 teintes
canal bleu sur 5 bits pour 2⁵= 32 teintes

Total donc 16 bits pour 2¹⁶= 65536 couleurs affichables, et un contrôleur écran fonctionnant donc au format RGB 565.

Sur les anciennes TI-Nspire monochromes, le langage interprété ne dispose hélas pas des fonctions de tracé.

Adaptons donc notre mire dans le langage de script Lua :

Code: Select all: o = false s = 1 function on.charIn(c) print(c) olds, oldo = s, o if c == "−" or c == "-" then s = -1 elseif c == "+" then s = 1 elseif c == "0" then s = 0 elseif c == "*" or c == "/" then o = not o end if s ~= olds or o ~= oldo then platform.window.invalidate() end end function on.resize(w, h) platform.window.invalidate() end function color8(j, v) l={0, 0, 0} for k = 1, #l do if math.floor(j / 2^(k - 1)) % 2 ~= 0 then l[k] = v end end return l end function on.paint(gc) pw = platform.window w, h = pw.width(), pw.height() if o then l1, l2 = h, w function f(gc, y, x1, x2, c) gc:setColorRGB(c[1], c[2], c[3]) gc:drawRect(x1, y, x2, y) end else l1, l2 = w, h function f(gc, x, y1, y2, c) gc:setColorRGB(c[1], c[2], c[3]) gc:drawRect(x, y1, x, y2) end end n = 8 for m = 0, l1 - 1 do v = 255 if s ~=0 then v = v * (s * m % l1) / (l1 - 1) end for j = 0, n - 1 do f(gc, m, j * l2 / n, (j + 1)*l2/n - 1, color8(j, v)) end end end

Sur les TI-Nspire monochromes nous avons donc 4 bits pour 2⁴= 16 niveaux de gris.

Sur Casio fx-CP400+E nous ne pouvons hélas pas te programmer de mire.

En effet dans le langage interprété historique de la machine et seul langage qui nous est accessible, le paramètre de couleur des fonctions graphiques ne peut prendre que 7 valeurs différentes.

Alors plan B, générons et enregistrons notre mire sous forme d'image, et convertissons-la en image .c2p pour la calculatrice à l'aide de notre convertisseur en ligne.

Toujours le même résultat avec 2 fois plus de teintes intermédiaires dans les tons de vert :

canal rouge sur 5 bits pour 2⁵= 32 teintes
canal vert sur 6 bits pour 2⁶= 64 teintes
canal bleu sur 5 bits pour 2⁵= 32 teintes

Total donc 16 bits pour 2¹⁶= 65536 couleurs affichables, et un contrôleur écran fonctionnant donc au format RGB 565.

On peut remarquer un petit bug d'affichage dans le dégradé de bleu, comme si la teinte la plus claire avait été marquée en tant que couleur transparente.

Mais ce n'est pas un bug lié à notre convertisseur, nous obtenons exactement le même défaut en utilisant le logiciel de conversion officiel de Casio.

Et enfin nous arrive la HP Prime.

Nous y bénéficions en Python d'une formidable zone graphique de 320×240 pixels.

Le module Python hpprime nous offre de quoi écrire un pixel : pixon(numero_calque,x,y,couleur).

Il ne fournit pas directement de quoi lire un pixel, mais par contre une fonction eval() permettant de faire appel au langage constructeur HPPPL où cette fonction existe. On peut alors se redéfinir une fonction get_pixel() en Python :