Forum TI-Planet.org

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

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

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 ?

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.

ça avance, 1er affichage sur KhiCAS :

La version compatible TI-Nspire KhiCAS est maintenant disponible :
archives_voir.php?id=2653460

La version NumWorks (et KhiCAS) optimisée est maintenant également disponible :
archives_voir.php?id=2653039

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!

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])))


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);
  }