Forum TI-Planet.org

Depuis ce mercredi tu n'es plus bridé dans ta créativité sur ta calculatrice NumWorks. En effet avec les nouvelles fonctionnalités de connectivité tu peux enfin archiver et restaurer tous tes scripts depuis la bibliothèque NumWorks et n'as donc plus à avoir peur de les perdre !

Plusieurs utilisateurs y ont déjà partagé certains de leurs scripts. Pas encore de jeux certes, mais on trouve entre autres des programmes graphiques, dont flocon.py par telpe51 qui te trace le flocon de Koch.

Il s'agit d'une fonction récursive à appeler dans la console via flocon(n), avec n un nombre entier naturel.

Par contre ne dépasse pas 41, car il semble que la calculatrice ne puisse actuellement empiler simultanément plus de 41 appels récursifs.
Qu'y a-t-il donc de si spécial avec 42 ?

Quoi qu'il en soit, il sera intéressant de vérifier quelles sont les limites des calculatrices Python concurrentes là-dessus. A bientôt.

Lien : https://workshop.numworks.com/python/telpe51/flocon
Source : https://workshop.numworks.com/python

C'est certainement lie a l'espace disponible pour la stack (ca affecte aussi un interpreteur Python normal, mais on s'en rend moins compte parce qu'il y a plus de RAM), chaque appel recursif en consomme, et comme il n'y a pas beaucoup de RAM, il y a encore moins de stack...

J'ai testé avec une fonction factorielle récursive.
Même limite sur NumWorks, et quasiment pareil sur Graph 90+E. C'est peut-être une option de compilation de Micropython.
Sur HP Prime par contre je peux aller bien au-delà, mais au bout d'un moment je finis par avoir un message d'avertissement même si la machine continue à retourner un résultat.

Testé en Python dans les trois cas, bien évidemment.

Je n'avais pas pensé à tester les limites de la récursivité ... C'est rigolo que ça tombe sur 42 ! Est-ce voulu ?...

Ce qu'on peut remarquer par contre, c'est que contrairement à la calculatrice le visualisateur en ligne échoue dès n=9 :

https://workshop.numworks.com/python/telpe51/flocon

Donc oui, ça doit venir de la mémoire limitée qu'il s'alloue.

Sinon, effrayant de voir qu'avec ce 'pauvre' flocon on se grille déjà 25% de l'espace de stockage de la machine.
Et je ne compte même pas les scripts préchargés là-dedans.

critor wrote:Sur HP Prime par contre je peux aller bien au-delà, mais au bout d'un moment je finis par avoir un message d'avertissement même si la machine continue à retourner un résultat.

J'ai implemente un evaluateur non recursif dans le CAS, je pense qu'il y a l'equivalent dans Home.

critor wrote:Ce qu'on peut remarquer par contre, c'est que contrairement à la calculatrice le visualisateur en ligne échoue dès n=9
[...]
Donc oui, ça doit venir de la mémoire limitée qu'il s'alloue.

C'est sans doute la limite de mémoire qu'il y a par defaut dans leur build emscripten
Ça devrait se changer facilement, ça, par contre, l'asm.js/webassembly peut décider de prendre beaucoup de RAM

D'ailleurs sur webcemu avec jacobly on a "résolu" le problème du thread bloquant - genre le freeze de toute la page pendant que l'émulateur calcule, ce qui est très moyen côté UX.
C'est probablement pour ça qu'ils ont limité la capacité de l'ému, pour avoir un calcul qui échoue au bout de x mémoire (donc n secondes) alors qu'en théorie ça pourrait être énorme sans problème.
C'est pas très compliqué à résoudre, juste que de temps en temps faut redonner la main au browser pour pas que l'utilisateur perçoive le freeze de la fenêtre/onglet. Cf. https://github.com/CE-Programming/CEmu/ ... emu.c#L219 + https://github.com/CE-Programming/CEmu/ ... .c#L27-L29

critor wrote:Sinon, effrayant de voir qu'avec ce 'pauvre' flocon on se grille déjà 25% de l'espace de stockage de la machine.
Et je ne compte même pas les scripts préchargés là-dedans.

Eh oui ... je n'ai déjà plus de place ! Il va falloir que je supprime des programmes ... , ennuyeux dilemne ! J'avais commencé à me faire une petite bibliothèque de formes géométriques (rien de bien avancé) et en jouer aléatoirement , mais là, il faut que je choisisse : je dois me conserver de la place pour d'autres programmes plus "terre à terre" . C'est dommage. Espérons que les prochaines mises à jour pallient le problème.

critor wrote:Sinon, effrayant de voir qu'avec ce 'pauvre' flocon on se grille déjà 25% de l'espace de stockage de la machine.
Et je ne compte même pas les scripts préchargés là-dedans.

En fait quelle est la quantité de RAM et de mémoire de stockage sur une NumWorks ?

puppy65 wrote:En fait quelle est la quantité de RAM et de mémoire de stockage sur une NumWorks ?

256Ko de SRAM.
Et apparemment, 4Ko de stockage pour les scripts Python.