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

[Lionel Debroux]

Super, merci pour tes tests. C'est beaucoup mieux, en effet

J'ai dû passer au maximum 5h sur la production de mon hack, donc je peux difficilement prétendre que c'était super compliqué, et du coup, des employés de TI auraient eux aussi pu le faire. Mais je peux comprendre qu'ils restent sur une config officiellement supportée par CircuitPython, plutôt que de trifouiller un peu le code pour passer dans une config non officiellement supportée. En tant que professionnel, si j'avais été à leur place, j'aurais peut-être eu à faire la même chose...

[critor]

C'est bien pour ça que, dans le contexte de la cible (lycée scientifique), il me semblait évident qu'il fallait choisir autre chose que CircuitPython.

[Lionel Debroux]

Certes, mais il fallait alors qu'ils choisissent un autre matériel qu'une des boards Adafruit limitées mais pas chères, qui ne sont gérées que par le fork de MicroPython par Adafruit qu'est CircuitPython - ou alors, qu'ils ajoutent la gestion d'une version réduite de ces boards Adafruit à MicroPython.

Les STM32F405RGT6 des PyBoard de référence pour MicroPython ( https://github.com/micropython/pyboard ) sont proches des processeurs des machines NumWorks, bien plus puissants que les membres de la famille ATSAMD21, mais au moins deux fois plus chers, aux alentours de 6 USD par 10000 pièces ( https://www.st.com/en/microcontrollers/stm32f405rg.html ) alors que les ATSAMD21 sont plutôt à 3 USD à l'unité au détail chez les revendeurs habituels (RS, Mouser).

[zardam]

Bravo !

Il y aura peut être une mise a jour officielle à la sortie de l'application pour le côté calculatrice, qui sait ?

Effectivement, le design a du être fortement dirigé par le coût. Ça reste quand même une perte sèche de fournir gratuitement les classes.

[parisse]

Approche du nombre dérivé par la limite du taux d'accroissement, Première.

Code: Tout sélectionner

def f(x):
  return x*x*x

def ta1(f,x,h):
  return (f(x+h)-f(x))/h

def ta2(f,x,h):
  return (f(x+2*h)-2*f(x+h)+f(x))/h/h

def table(f,x,n):
  for i in range(n):
    h=10**-i
    print(h,ta1(f,x,h),ta2(f,x,h))

Sur toutes les pythonnettes qui se comportent bien, on voit que la précision s'améliore au fur et à mesure des itérations qui travaillent sur des valeurs h de plus en plus petites :

En fait, non, c'est un exercice d'analyse numerique de montrer qu'il y a une valeur de h optimale pour approcher f' qui depend bien sur de la formule utilisee et du nombre de chiffres significatifs des flottants. Si on diminue h au-dela de cette valeur optimale, la precision sur f' diminue.

[jean-baptiste boric]

Je conçois que chez TI c'est un peu la panique depuis un certain temps, mais là... bon, après tout on n'est pas à l'abri d'un firmware miracle d'ici à la sortie de l'application PyAdaptr, autant l'attendre avant de tirer sur l'ambulance.

Pour sa défense, le module n'est certes pas très véloce, mais on reste raisonnablement proche du niveau que la concurrence offre sur ce créneau (la NumWorks ne gère pas des flottants 64 bits dans son FPU non plus). Le problème du module n'est pas matériel, mettre un microcontrôleur plus puissant n'aurait pas changé grand chose ici au final, mais clairement logiciel. Ils ne se sont même pas pris la peine de prendre une petite journée pour corriger les flottants?

[jean-baptiste boric]

En fait, non, c'est un exercice d'analyse numerique de montrer qu'il y a une valeur de h optimale pour approcher f' qui depend bien sur de la formule utilisee et du nombre de chiffres significatifs des flottants. Si on diminue h au-dela de cette valeur optimale, la precision sur f' diminue.

Le vrai problème est que le module exhibe un comportement différent (et de plus en sa défaveur) vis-à-vis de ses concurrents sur un point (LE point) où il ne devrait pas. Un professeur qui teste sur un ordinateur ou une autre calculette va avoir une mauvaise surprise en classe (ou pire, en DS ou au BAC) quand certains de ses élèves ne vont pas obtenir les résultats attendus, comme critor l'a montré sur de nombreux exemples.

Le choix Python est motivé par son côté universel, où un programme fonctionnera de manière identique, quelque soit le modèle de calculatrice (ou d'ordinateur). Là, c'est clairement un raté caractérisé de la part de TI, qui devrait pourtant être sensibilisé sur les problèmes de précision de calcul... C'est pas comme s'ils vendaient des calculettes après tout

[critor]

Que l'on soit clair, les problèmes que j'exhibe avec les flottants existent sur toutes les plateformes, que la précision soit :

• sur 53 bits (double précision Python)
• sur 24 bits (simple précision Python)
• sur 22 bits (cas particulier de la simple précision du CircuitPython)

C'est juste que dans ce dernier cas les problèmes se déclenchent beaucoup plus tôt dans les itérations/récursions, tellement qu'il est parfois impossible d'exploiter les résultats (impossible de vérifier, conjecturer...).
Se déclenchant plus tôt, les problèmes sont donc rencontrés beaucoup plus souvent.

Le 24 bits est déjà considéré par nombre d'acteurs du monde informatique comme n'étant quasiment jamais suffisant, alors imaginez le spécial 22 bits de CircuitPython...


Le module TI-Python / Adafruit est sympa, mais pour moi c'est un jouet. Un jouet destiné à faire découvrir le Python aux jeunes (primaire, collège), ou à aider à monter des projets technologiques.

Dans le contexte scientifique du lycée, il est clairement inadapté. Une calculette 4 opérations de primaire fait mieux, c'est dire...
Il peut certes être fort intéressant/amusant en classe de Maths/ICN/Informatique/Numérique/Technologie d'étudier pourquoi le TI-Python répond faux.
Mais aux devoirs/examens écrits ce ne sera pas amusant, ce sera pénalisant !

Certes, il restera aux élèves en question la possibilité de chercher/vérifier leurs réponses avec le langage historique de leur 83PCE.
Mais les élèves connaissant ce langage vont être de moins en moins nombreux suite aux nouveaux programmes.

[critor]

Question.

En Python 3, est-ce qu'il est possible de tester si un entier est long ou court ?

Ou plus précisément, est-il possible de déterminer la valeur frontière entre entiers longs et courts, lorsque l'on ne dispose pas du sys.maxsize ?

Merci.

[Noury]

Il me semble bien qu'en python 3 on ne fasse pas la distinction entre entier long et entier court. Tout est "int".
La représentation interne dépend elle de l'architecture.
En Python 2, la distinction existe.
À vérifier tout de même.