Module TI-Python disponible à l'unité chez Jarrety : 13,50€

→ **MyCalcs** profile · by **parisse** » 06 Feb 2019, 20:57

Oui, je suis bien d'accord, c'est juste que le message que je commentais pouvait laisser l'impression que le probleme de precision sur le calcul de f' n'existait qu'avec des floats simple precision. Voir par exemple la session de Xcas en ligne
session Xcas

Ca laisse quand meme songeur tout ca. On a du mal a croire que TI n'ait pas les ressources pour adapter vers des flottants double precision. Je me demande s'ils n'ont pas sous-traite l'affaire en externe et low-cost.

→ **MyCalcs** profile · by **critor** » 06 Feb 2019, 21:24

Ah parisse, bonsoir.

Pas impossible qu'ils aient sous-traité à des personnes qui ont visiblement complètement zappé le contexte de la cible (lycée et très majoritairement sections scientifiques), pour nous avoir choisi une technologie tout juste digne d'un jouet de découverte/initiation Python.

Pendant que vous êtes sur ce topic, quelque chose qui cloche dans mon script de test de performances sans flottants ?
viewtopic.php?f=41&t=22242&start=90#p239524

Parce qu'il relègue les HP Prime et KhiCAS aux dernières places, ce à quoi je ne m'attendais pas.

→ **MyCalcs** profile · by **parisse** » 07 Feb 2019, 07:24

En regardant rapidement le source, il y a des myabs et sgn qui semblent inutiles, mais je pense que c'est plutot l'affectation dans une liste qui est nettement plus lente car avec = l'affectation se fait par valeur, donc avec copie complete de la liste. Il faut utiliser =< pour faire une affectation par reference comme en Python.
C'est a mon sens plus intuitif quand on debute qu'apres la suite d'instructions
l=[1,2,3]; m=l; l[0]=0;
m[0] renvoie 1
Je testerai plus en detail des que j'ai un peu de temps.

→ **MyCalcs** profile · by **parisse** » 07 Feb 2019, 08:25

Ca semble etre surtout sgn vs sign qui ralentit (l'affectation par reference ne change pas grand chose car la taille de la liste n'est pas tres grande). En fait ce script teste principalement la vitesse d'interpretation. Du coup c'est normal qu'un interpreteur base sur un noyau d'evaluation CAS soit beaucoup plus lent. Ceci se compense (partiellement) par les instructions utilisables nativement, ici la fonction sign qui semble absente en Python (je decrouvre ca, c'est quand meme tres etonnant!!!) alors qu'elle est presente dans Xcas comme dans tout logiciel de calcul/calculatrice.

→ **MyCalcs** profile · by **parisse** » 07 Feb 2019, 10:13

Teste avec KhiCAS sur la Casio: si on remplace sgn par sign, le temps d'execution est presque divise par 3 : 74 secondes. Je n'ai pas teste sur les Prime, on gagne tres probablement le meme facteur 3 environ.

→ **MyCalcs** profile · by **samourai3745** » 07 Feb 2019, 11:31

critor wrote:Ah parisse, bonsoir.

Pas impossible qu'ils aient sous-traité à des personnes qui ont visiblement complètement zappé le contexte de la cible (lycée et très majoritairement sections scientifiques), pour nous avoir choisi une technologie tout juste digne d'un jouet de découverte/initiation Python.

Pendant que vous êtes sur ce topic, quelque chose qui cloche dans mon script de test de performances sans flottants ?
viewtopic.php?f=41&t=22242&start=90#p239524

Parce qu'il relègue les HP Prime et KhiCAS aux dernières places, ce à quoi je ne m'attendais pas.

Bonjour Critor,

J'ai essayé ton prog sur ma G90+e, j'obtiens 15,129s avec le module python Casio et System error reboot address(r) target=DF1ED41F pc=00000000 avec le module Khicas du 20 janvier. Bizarre

J'espère que pour le module TI une correction sera apportée, sinon cela reste juste un bidule de démo de ce que pourrait être Python et non un module python.

→ **MyCalcs** profile · by **Lionel Debroux** » 07 Feb 2019, 12:24

Allez, encore un petit build trafiqué de CircuitPython. Par rapport au précédent, j'ai mis cmath, ce qui prend ~2.5 KB, et donc, pour que le binaire puisse rentrer dans les 184 KB de Flash réservés, j'ai dû tailler dans les modules spécifiques à la board (nommés *io), et un peu le code d'init... j'espère donc que ça fonctionne sur board réelle...

Merci d'avance à ceux qui testeront.
Il serait intéressant d'énumérer les modules dans ce build, pour voir les différences avec le TI-Python Adapter et les gains potentiels de place (module microcontroller, par exemple ?). La liste des modules postée par critor à https://ti-pla.net/p239442 était très restreinte, après tout.

Notes diverses:
* il reste busio I2C et busio SPI, mais ça ne gagne pas beaucoup. Si on enlève tout SPI et I2C, on va peut-être pouvoir gagner 1-2 KB, mais est-ce qu'on peut réellement le faire (parce que, par exemple, I2C et SPI ne s'avéreraient pas utilisés sur la board, et ne sont de toute façon pas accessibles physiquement si on laisse le PCB dans sa boîte plastique) ?
* certaines fonctions de maths coûtent très cher en place: pow est proche de 2.5 KB (!), expm1 fait ~1 KB, log 560 octets, __rem_pio2_large 0x540 malgré de la propagation de valeurs constantes, mp_format_float 0x54c octets malgré la même optimisation;
* on gagne ~2 KB en utilisant MICROPY_ERROR_REPORTING_TERSE, mais bien sûr, l'utilisabilité va s'en ressentir;
* si j'active MICROPY_PY_URANDOM_EXTRA_FUNCS, je passe très légèrement au-delà de la limite;
* si j'active MICROPY_PY_MATH_SPECIAL_FUNCTIONS, je monte 6 KB au-delà de la limite.

Bref... une nouvelle fois, TI, il ne fallait pas choisir ce matériel de m*, c'est tout...

Code: Select all: LINK build-trinket_m0/firmware.elf 360 bytes free in flash out of 188416 bytes ( 184.0 kb ). 26596 bytes free in ram for stack out of 32768 bytes ( 32.0 kb ). Create build-trinket_m0/firmware.bin Create build-trinket_m0/firmware.uf2 Converting to uf2, output size: 376320, start address: 0x2000 Wrote 376320 bytes to build-trinket_m0/firmware.uf2.

→ **MyCalcs** profile · by **parisse** » 07 Feb 2019, 14:29

Nouvelle illustration de la stupidite de vouloir economiser quelques piecettes sur la memoire, apres on est oblige de se torturer pour faire rentrer en memoire ce dont on a envie avec un gros risque d'introduire des bugs.
Lire que 2.5K c'est tres cher en place de nos jours c'est quand meme ubuesque!

→ **MyCalcs** profile · by **Lionel Debroux** » 07 Feb 2019, 14:38

On est d'accord, TI a merdé, beaucoup plus que NumWorks

Depuis le build précédent, j'ai enlevé quelques modules, assez pour pouvoir annuler certains de mes hacks, mais pas encore assez pour mettre, par exemple, les fonctions spéciales de math, qui n'y sont pas dans le build de TI.

My calculator programs · by **Adriweb** » 07 Feb 2019, 15:13

parisse wrote:Teste avec KhiCAS sur la Casio: si on remplace sgn par sign, le temps d'execution est presque divise par 3 : 74 secondes. Je n'ai pas teste sur les Prime, on gagne tres probablement le meme facteur 3 environ.

Au passage, on peut remplacer ceci du script initial

Code: Select all: def myabs(x): if x<0: x=-x return x def sgn(x): if x!=0: return x/myabs(x) else: return 0

par ceci :

Code: Select all: def sgn(x): return x and (1 if x>0 else -1)

ou

Code: Select all: def sgn(x): return x and (1, -1)[x < 0]

ou

Code: Select all: sgn = lambda x: x and (1 if x>0 else -1)

ou

Code: Select all: sgn = lambda x: x and (1, -1)[x < 0]

Edit: si on a math d'importé, on peut faire appel à la fonction copysign, aussi :

Code: Select all: def sign(x): return x and copysign(1, x)

En tout cas pour python 3 / micropython / circuitpython

Pour garder la compat avec giac/khicas, il faudrait quelque chose du genre :

Code: Select all: def sgn(x): if x>0: return 1 elif x<0: return -1 else: return 0

Bref, tout ça évite un appel de fonction, une division, etc.

J'ai loupé quelque chose que la division gérait autrement, ou pas ?

Et @parisse ce ne serait pas possible de gérer la syntaxe du short if dans l'exemple return x and (1 if x>0 else -1) ? Parce que pour le coup, même si je ne suis pas fan des que c'est ça dépasse juste une seule valeur comme ici, c'est quelque chose de très courant en Python...