Mise à jour matplotlib Casio Graph 90/35+E II : arrow()
Posted: 18 Aug 2020, 10:30
Pour cette rentrée 2020, la formidable application Python des Casio Graph 90+E et Graph 35+E II si correctement mise à jour (ce qu'il est notamment conseillé de faire si tu viens d'acheter la calculatrice) t'offre 3 modules importables pour tes scripts :
De plus, Casio diffuse 2 scripts Python à rajouter manuellement dans ta calculatrice et qui s'appuient sur le module casioplot précédent :
Tous les liens de téléchargement seront disponibles en fin d'article.
- math pour les fonctions mathématiques, un standard
- random pour l'aléatoire, un standard
- et casioplot, un module graphique propriétaire permettant à tes scripts d'allumer des pixels de l'écran dans la couleur de ton choix
De plus, Casio diffuse 2 scripts Python à rajouter manuellement dans ta calculatrice et qui s'appuient sur le module casioplot précédent :
- turtle.py, un script fantastique de plus de 300 lignes qui reproduit sur ta calculatrice le fonctionnement du module turtle standard
- matplotl.py, un script monumental de plus de 600 lignes qui s'occupe quant à lui de reproduire sur ta calculatrice le fonctionnement du module standard matplotlib.pyplot
Tous les liens de téléchargement seront disponibles en fin d'article.
Cela n'enlève rien à leurs énormes qualités supérieures par rapport à ce qui est disponible sur certaines Pythonnettes concurrentes, mais une réécriture intégrale ne peut pas être parfaite du premier coup.
Nous nous intéresserons ici au script matplotl.py, et plus précisément à sa fonction de tracé de flèche/vecteur notamment pour l'enseignement de Physique-Chimie en Seconde, arrow().
Absolument pas pour se moquer de Casio, mais simplement parce que c'est intéressant et hautement formateur.
Voici un petit script avec de quoi te tracer un soleil de vecteurs (ou un champ de vecteurs radial pour ceux qui préfèrent) :
Bon la NumWorks semble ignorer les paramètres de couleur pour faire absolument n'importe quoi, mais ce n'est pas ce qui nous intéresse aujourd'hui. Voyons donc plutôt les défauts chez Casio.
Sur Graph 35+E II tout semble bon. Par contre sur Graph 90+E il y a un problème avec la couleur des pointes, dans le cas particulier où elles sont orientées horizontalement ou verticalement.
Nous nous intéresserons ici au script matplotl.py, et plus précisément à sa fonction de tracé de flèche/vecteur notamment pour l'enseignement de Physique-Chimie en Seconde, arrow().
Absolument pas pour se moquer de Casio, mais simplement parce que c'est intéressant et hautement formateur.
Voici un petit script avec de quoi te tracer un soleil de vecteurs (ou un champ de vecteurs radial pour ceux qui préfèrent) :
- Code: Select all
try:
from matplotlib.pyplot import *
except ImportError:
from matplotl import *
from math import cos, sin, pi
def radians(x):
return x * pi / 180
def autoround(x):
xr = round(x, 0)
if abs(x - xr) < 10 ** -15:
x = xr
return x
def rotarrow(x0, y0, rx, ry, t1, t2, ts, hw, hl, ec, fc):
for k in range(t1, t2 + ts, ts):
kr = radians(k)
w, h = autoround(rx * cos(kr)), autoround(ry * sin(kr))
arrow(x0, y0, w, h, head_width=hw, head_length=hl, ec=ec, fc=fc)
Graph 35+E II | Graph 90+E | NumWorks | ordi |
|
Bon la NumWorks semble ignorer les paramètres de couleur pour faire absolument n'importe quoi, mais ce n'est pas ce qui nous intéresse aujourd'hui. Voyons donc plutôt les défauts chez Casio.
Sur Graph 35+E II tout semble bon. Par contre sur Graph 90+E il y a un problème avec la couleur des pointes, dans le cas particulier où elles sont orientées horizontalement ou verticalement.
Effectivement ça ne va pas, tentons de comprendre et corriger directement le fichier de Casio puisque ce dernier a eu la gentillesse de laisser le code source consultable et modifiable contrairement à d'autres.
La variable color est donc la couleur utilisée pour le tracé du segment via un appel plot() commun à toutes les orientations.
La variable headcolor est quant à elle la couleur souhaitée pour la pointe.
Pour le tracé de la pointe il y a 2 cas particuliers pour les directions horizontales et verticales, et effectivement les appels plot() associés sont faux, réutilisant color comme paramètre de couleur. La correction est triviale, lignes n°23 et 29 dans les extraits de code ci-dessous :
La variable color est donc la couleur utilisée pour le tracé du segment via un appel plot() commun à toutes les orientations.
La variable headcolor est quant à elle la couleur souhaitée pour la pointe.
Pour le tracé de la pointe il y a 2 cas particuliers pour les directions horizontales et verticales, et effectivement les appels plot() associés sont faux, réutilisant color comme paramètre de couleur. La correction est triviale, lignes n°23 et 29 dans les extraits de code ci-dessous :
maptplotl.py de Casio | matplotl.py corrigé |
|
|
Bon mais ça c'était un détail. Voici maintenant beaucoup plus dérangeant et épicé :
Mais sur Graph 35+E II et Graph 90+E ça ne va pas du tout... Mais qu'est-ce que c'est que cette horreur de soleil à moitié fané ?...
Dans certains cas, les pointes de flèches/vecteurs sont visiblement tracées à l'envers. Là pour le coup c'est un bug bien plus profond et non une simple étourderie.
Tentons de comprendre un peu mieux quand est-ce que cela se produit :
Graph 35+E II | Graph 90+E | NumWorks | ordi |
|
Mais sur Graph 35+E II et Graph 90+E ça ne va pas du tout... Mais qu'est-ce que c'est que cette horreur de soleil à moitié fané ?...
Dans certains cas, les pointes de flèches/vecteurs sont visiblement tracées à l'envers. Là pour le coup c'est un bug bien plus profond et non une simple étourderie.
Tentons de comprendre un peu mieux quand est-ce que cela se produit :
Graph 35+E II | Graph 90+E | NumWorks | ordi |
|
Il semble que les pointes de flèches soient ainsi montées à l'envers lorsqu'elles ont une abscisse négative (x<0). Il s'agirait donc a priori d'une erreur de signe, faut-il encore trouver où changer le signe dans le code.
Notons que le problème concerne des flèches qui ne sont ni horizontales ni verticales, et l'erreur est donc à chercher cette fois-ci dans le bloc traitant le cas général. Or il y a justement un test de signe dans ce cas, ligne 34 ci-dessous. Changeons cela...
Notons que le problème concerne des flèches qui ne sont ni horizontales ni verticales, et l'erreur est donc à chercher cette fois-ci dans le bloc traitant le cas général. Or il y a justement un test de signe dans ce cas, ligne 34 ci-dessous. Changeons cela...
maptplotl.py de Casio | matplotl.py corrigé |
|
|
Ah ben non, ce n'est pas encore ça... cela corrige bien les pointes enfichées sur une extrémité de segment d'abscisse négative, mais pas celles qui franchissent l'axe des ordonnées donnant donc une pointe d'abscisse négative bien que montée sur une extrémité d'abscisse positive.
Les deux sens de montage de la flèche pour l'orientation du segment sont en fait retournées en abscisses par un appel resol(), simple fonction donnant les racines d'un polynôme du second degré.
Reste donc à choisir le bon sens de montage, et le test officiel
En fait nous ne voyons même pas en quoi la réponse dépendrait du signe de la racine
Faire pointer à gauche ou à droite, non ici cela ne dépend plus que d'une seule et unique chose, le signe de dx, et le bon test corrigé en ligne 34 ci-dessous est donc
On peut bien se permettre une petite coquille après s'être tapé plus de 320 lignes.
En attendant une mise à jour officielle qui réglera cela et peut-être d'autres choses, c'est donc cette version corrigée que nous distribuerons.
Les deux sens de montage de la flèche pour l'orientation du segment sont en fait retournées en abscisses par un appel resol(), simple fonction donnant les racines d'un polynôme du second degré.
Reste donc à choisir le bon sens de montage, et le test officiel
S[0]*dx<0
ainsi que notre test S[0]*dx*x<0
semblent donc tous les deux faux.En fait nous ne voyons même pas en quoi la réponse dépendrait du signe de la racine
S[0]
... à la rigueur de l'ordre de S[0]
et S[1]
pour savoir qui est à gauche et qui est à droite, mais pas du signe... et ici il n'y a même pas à se préoccuper de l'ordre puisque 1+1/m**2
, premier paramètre de l'appel resol(), est strictement positif.Faire pointer à gauche ou à droite, non ici cela ne dépend plus que d'une seule et unique chose, le signe de dx, et le bon test corrigé en ligne 34 ci-dessous est donc
dx<0
.On peut bien se permettre une petite coquille après s'être tapé plus de 320 lignes.
maptplotl.py de Casio | matplotl.py corrigé |
|
|
En attendant une mise à jour officielle qui réglera cela et peut-être d'autres choses, c'est donc cette version corrigée que nous distribuerons.
Téléchargements :
- Mise à jour 3.30 de la Graph 35+E II (pour Windows)
- Mise à jour 3.40 des Graph 90+E / fx-CG50 (pour Windows / Mac)
- interface turtle.py pour Graph 35+E II / Graph 90+E / fx-CG50
- interface matplotl.py pour Graph 35+E II / Graph 90+E / fx-CG50