Solar, le système Solaire en Python sur NumWorks, TI, Casio

[critor]

Si d'une façon ou d'une autre tu es passé·e dans un collège ou lycée au milieu des années 1990, peut-être te souviens-tu du logiciel

PC Univers

également connu sous le nom de

Orbits : voyage à travers le système solaire

, la banque de données sur le système solaire, dont on retrouvait une copie sur la plupart des ordinateurs

286/386/486

laissés en accès libre.

Sorti en 1991, le logiciel était distribué en France par

Nathan Logiciels

, éditeur qui s'était popularisé la décennie précédente sous le nom de

Cédic Nathan

dans le contexte du plan

IPT

(

I

nformatique

P

our

T

ous)

avec les microordinateurs

Thomson MO5

et

TO7

.

Il s'agissait en fait d'une francisation du logiciel américain

Orbits : Voyage Through the Solar System

par

WinterTech

.

Jil Saint-Martin

et

Emmy Vadon

débutent l'enseignement de spécialité spécialité

NSI

(

N

umérique et

S

ciences

I

nformatiques)

en Première au lycée

Louis Pasteur

d'

Avignon

.

Leurs enseignants exigeants leur ont déjà demandé de concevoir et rendre pour les congés de Toussaint un premier projet

Python

complet sur calculatrice

NumWorks

.

Grâce à

Jil

et

Emmy

, voici donc dès maintenant la nouvelle référence à installer sur toutes les calculatrices

NumWorks

:

Solar :

une brève navigation dans l'espace sur Python

!

Solar

est donc une banque de données sur le système solaire, comparable à

PC Univers

.

Elle bénéficie toutefois d'une bien meilleure intuitivité et interactivité. Pas d'horrible menu de haut d'écran à dérouler et lire ici, tout se contrôle avec les touches fléchées du clavier, avec un retour visuel immédiat.
Flèches gauche et droite pour choisir son étoile ou planète alors mise en surbrillance, et flèches haut et bas pour en faire défiler les différentes propriétés.

Près de 30 ans après

Solar

a également le gros avantage de bénéficier de données à jour, c'est-à-dire que

Gil

et

Emmy

se sont donné la peine de supprimer tout ce qui concernait

Pluton

.

Non plus sérieusement

aux âmes bien nées la valeur n'attend point le nombre des années

, toutes nos félicitations à

Jil

et

Emmy

qui ont su relever des défis ambitieux et développer de belles capacités et compétences. On peut retenir entre autres :

• déjà de base des qualités artistiques et graphiques indéniables
• une belle maîtrise du codage des couleurs
  RVB
  , superbement exploitée ici dans le contexte des dégradés
• un beau travail de recherche sur le tracé de cercles dans le contexte de la géométrie et du théorème de
  Pythagore
  (aucune fonction en ce sens n'étant actuellement fournie par la bibliothèque de tracé par pixels

  kandinsky

  de la

  NumWorks

  )
  , basé sur le travail de
  Philippe Moutou
  , avec des fonctions soigneusement calibrées pour ne pas laisser de trous dus aux arrondis lors du remplissage d'un disque en dégradé
• et toute la logique algorithmique permettant d'afficher tout ça, notamment en terme de boucles

N'hésite pas à aller consulter leur compte-rendu pour plus d'informations.

Mais peut-être n'as-tu pas de

NumWorks

?

Et bien ne t'inquiète pas car n'étant pas sectaires et afin que personne ne soit privé, nous nous sommes de notre côté occupés de la compatibilité universelle de

Solar

, grâce à la bibliothèque

polycalc

que nous avons créée dans le cadre de notre concours

Python

de rentrée

2020

et que nous avons fait évoluer ici avec de nouvelles fonctions, notamment pour la détection des touches clavier.

Le chef-d'œuvre de

Jil

et

Emmy

est dès maintenant disponible sur

TI-Nspire CX II

!

Ce fut l'adaptation la plus facile, nous avons juste eu à effectuer les connexions à notre bibliothèque et ça marche tout seul.

La compatibilité

Casio Graph 90+E / fx-CG50

fut plus compliquée. Le gros défaut à ce jour de leur solution

Python

est qu'elle ne fournit pas de fonction pour tester les appuis de touches clavier. La seule touche que l'on peut détecter c'est la touche

AC/ON

, en interceptant et détournant l'exception d'interruption qu'elle génère.

Nous avons donc ici dû adapter le fonctionnement ; il faut taper

AC/ON

pour passer à la planète ou étoile suivante, et les différentes propriétés défilent automatiquement.

Mais bon, ce n'était rien ça encore... La compatibilité

TI-83 Premium CE Edition Python

et

TI-84 Plus CE-T Python Edition

fut hautement plus complexe. L'ennui étant que le script original est conçu pour exploiter une mémoire de tas

Python

de

32K

, et ici nous nous disposons que de

16K

...

Ce ne fut pas facile, mais heureusement le code de

Jil

et

Emmy

était encore grandement optimisable. Données dupliquées, fonctions de tracé remplacées par les appels natifs lorsque disponibles, variables globales effacées une fois utilisées... Après plusieurs heures de casse-tête eurêka ça marche !

Nous faisons d'ailleurs profiter rétroactivement de nos adaptations précédentes de ce code optimisé.

Et pour les curieux, petite comparaison contextualisée des performances :

1. 4s
   -
   TI-Nspire CX II
   : avec un affichage en
   double buffering
   et nombre de fonctions de tracé natives
2. 12s
   -
   NumWorks
   : pas de
   double buffering
   , et les fonctions de tracé natives sont extrêmement réduites, juste de quoi remplir un rectangle ce qui ne nous aide pas ici, les cercles et disques sont donc dessinés dans le code pixel par pixel
3. 1min49s
   -
   Casio Graph 90+E / fx-CG50
   : affichage en
   double buffering
   , mais pas de fonctions de tracé natives en dehors de l'allumage de pixels isolés
4. 2min36s
   -
   TI-83 Premium CE Edition Python / TI-84 Plus CE-T Python Edition
   : pas de
   double buffering
   , riche bibliothèque de fonctions de tracé natives, mais la communication à chaque appel de fonction graphique entre le coprocesseur
   Python Atmel
   et le processeur principal historique
   eZ80
   s'occupant de l'écran fait office de goulot d'étranglement

Téléchargements

:

• Solar
  (pour

  NumWorks

  - original)
• Solar
  (pour

  NumWorks

  et

  KhiCAS

  )
• Solar
  (pour

  TI-Nspire CX II

  )
• Solar
  (pour

  TI-Nspire

  avec

  Ndless

  +

  KhiCAS

  )
• Solar
  (pour

  Casio Graph 90+E / fx-CG50

  )
• Solar
  (pour

  TI-83 Premium CE Edition Python / TI-84 Plus CE-T Python Edition

  )

Lien

:

https://nsi.xyz/Une-breve-navigation-da ... sur-python

[Nagero]

C'est vraiment incroyable graphiquement !
Dommage que la TI83 galère autant à l'afficher

[cent20]

Un grand merci à toi Xavier d'avoir porté ce projet sur les autres calculatrices et pour la qualité de cet article.

La supériorité de la Nspire est bien incontestable pour le coup, clairement il manque des fonctions natives sur la NumWorks.

Au départ, elles souhaitaient faire un menu dans la console, avec une sélection dans la console, l'affichage graphique, puis un retour des informations dans la console, j'ai pu orienter leur réflexion en éliminant toutes les entrées / sorties en console, et ainsi leur permettre de faire un projet NoPrint, NoInput, même si elles sont très loin de ces considérations d'experts en programmation. (coucou twitter !)

Précisons que nous n'aurions jamais demandé à nos élèves de faire un projet sur la ti83 PCE. Nous avons tenté de les utiliser avec les adaptateurs python, utilisé une unique fois, on n'est pas fous non plus. Même chose sur une TI 83 PCE python édition, la taille du tas est bien trop juste, et les capacités graphiques de la calculatrice (affichage graphique en python) bien trop limité, cela aurait été décourageant pour tout le monde.

Après je reconnais que, le temps incroyablement long que met la TI 83 à afficher le système solaire rajoute une pointe de mystère et permet de se bien prendre conscience des distances absolument colossales entre les planètes. Je pense que c'est pour coller le plus possible à la réalité que TI a doté la TI 83 de ces incroyables performances

Pour être capable de pouvoir envisager ce projet, j'ai légèrement spammé la boite email de NumWorks entre juillet 2019 et mars 2020, jusqu'à ce que enfin, un tas correct (mémoire d'exécution) soit alloué par la machine à son application python. Je ne dis pas que 32ko c'est le rêve, mais c'est un bon début. Je ne dis pas non plus que mon mailing intensif a été décisif dans la doublement du tas python, je ne crois plus au père Noël depuis longtemps.

heureusement le code de Jil et Emmy étant encore grandement optimisable

Après le début des vacances, et donc les 7 heures de recherche en classe, je m'interdis (et mon collègue également) de retoucher le code des élèves ou de les aider directement, sauf en publiant des portions de code générique adaptable à la demande. J'ai bien repéré les données dupliquées, les tracés directs, les vestiges de leur code initial, les listes en tableau et pas un tuple, mais j'essaye de respecter la règle que nous nous sommes fixé, règle connu des élèves. " Avant le début des vacances on peut vous aider, après c'est fini "

L'étude du code optimisé peut-lui même être un excellent travail, j'ai regardé le code pour la TI 83 il y a plein d'astuces rigolotes. Où as tu déposé ta version .py optimisé pour NumWorks ?

[critor]

Merci pour ton retour.

Pour la version

NumWorks

, j'attends une réponse de

parisse

afin de savoir si une compatibilité est possible avec

KhiCAS

en mode

Micropython

.
Sinon tu peux copier le code de la version

TI-Nspire CX II

, le code y est complet et non spécifique, vu la formidable taille de

heap

.
Il suffit juste ensuite éventuellement d'alléger

polycalc.py

pour la

NumWorks

.

[critor]

ça avance, 1er affichage sur KhiCAS :

[critor]

La version compatible

TI-Nspire KhiCAS

est maintenant disponible :
archives_voir.php?id=2653460

[critor]

La version

NumWorks

(et

KhiCAS

)

optimisée est maintenant également disponible :
archives_voir.php?id=2653039

[parisse]

Excellent!
Quelques suggestions d'amelioration pour la version KhiCAS
1/ accelerer cercle_grade s'il n'y a pas de degrade

Code: Select all

def cercle_grade(x0,y0,R,c1,e,c2):
  if c1==c2:
    return fill_circle(x0,y0,R,c1)
  for i in range(R):
    cercle(x0,y0,i,(c1[0]+i*(c2[0]-c1[0])//R,c1[1]+i*(c2[1]-c1[1])//R,c1[2]+i*(c2[2]-c1[2])//R),1)


2/ commenter sleep(0.120) dans navigation et mettre sleep(0.1) au lieu de sleep(1)

Comme ca, la navigation est fluide, y compris sur la nspire CX.
Je mettrai bien tout ca dans l'archive pour Nspire si les divers auteurs sont d'accord!

[parisse]

Autre optimisation sur l'initialisation en fonds d'etoile (tirage(250))

Code: Select all

def tirage(n):
  c=(couleur2[0],(13,89,175),(13,89,175),(44,122,211),(207,230,230),(207,230,230),couleur2[0])
  sw2=screen_w//2
  sh2=screen_h//2
  coeff=1.0/(screen_w/10+.5)
  for i in range(n):
    x=randint(0,screen_w)
    y=randint(0,screen_h)
    d=sqrt((x-sw2)**2+(y-sh2)**2)*coeff
    di=int(d)
    if di==1 or di==4:
      fill_rect(x,y,2,2,c[di])
    else:
      k=d-di
      k1=1-k
      c1=c[di]
      c2=c[di+1]
      fill_rect(x,y,2,2,(int(k1*c1[0]+k*c2[0]),int(k1*c1[1]+k*c2[1]),int(k1*c1[2]+k*c2[2])))


[parisse]

Je viens de tester sur la Numworks, en faisant la modif pour cercle_grade, sleep, ainsi qu'une modif pour tirage en utilisant le codage des couleurs par un seul entier pour accelerer le calcul du degrade:

Code: Select all

def rgb(r,g,b):
  return ((((r*32)//256)<<11) | (((g*64)//256)<<5) | ((b*32)//256))

def tirage(n):
  c=[rgb(235,128,0),rgb(13,89,175),rgb(13,89,175),rgb(44,122,211),rgb(207,230,230),rgb(207,230,230)]
  c.append(c[0])
  sw2=screen_w//2
  sh2=screen_h//2
  coeff=1.0/(screen_w/10+.5)
  for i in range(n):
    x=randint(0,screen_w)
    y=randint(0,screen_h)
    d=sqrt((x-sw2)**2+(y-sh2)**2)*coeff
    di=int(d)
    fill_rect(x,y,2,2,c[di]+int((d-di)*(c[di+1]-c[di])))


et l'utilisation directe de graphic.fill_rect, le trace se fait en 2 ou 3 secondes, avec en plus une impression de generique de debut avec l'affichage du fonds d'ecran en direct. Sur la Nspire CX II ca va a la meme vitesse, mais on n'a pas cette impression de generique.

Une petite remarque, la fonction draw_string de polysol devrait faire print(s) au lieu de print(st) (qui devait servir au debug).

Il y a un truc bizarre, c'est que les planetes sont coupees en 2, je veux dire que l'affichage de la separatrice droite/gauche des ellipses qui les representent est incomplet, ce qui doit venir d'une des primitives de trace, ici draw_arc et en examinant le code source, je me demande si le comportement de int() en C est le meme sur tous les CPU, comme ici pour la fonction set_pixel lorsque x et y sont entiers representes par des double

Code: Select all

  void set_pixel(double x,double y,int c,GIAC_CONTEXT){
    os_set_pixel(int(x+.5),int(y+.5),c);
  }