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

[critor]

Un exemple.

Algo de seuil sur une suite convergente, niveau Terminale S.

Code: Select all

from math import *
def seuil(d):
  n=0
  u=2
  l=1
  while abs(u-l)>=d:
    n=n+1
    u=1+(1/((1-u)*(n+1)))
  return n

seuil(d) détermine à partir de quel rang n on sera à moins de d de la limite.
Il n'est pas rare de demander quand est-ce qu'on en sera à un dixième, un centième, un millième...

Exemple : ne frappons pas trop fort, prenons un seuil de 0.03 soit 3 centièmes.
Toutes les pythonnettes ainsi que mon ordi répondent ça :

>>> from seuil import *
>>> seuil(0.03)
707

Pareil dans le langage interprété historique de chaque calculatrice :


Mais avec le TI-Python qui ne sait pas calculer correctement, oh que non...

>>> seuil(0.03)
709

Imaginez recopier ça au BAC pour un QCM ou quand un exo demande ce qu'affiche tel ou tel algo !
Comme ce sont des questions sans justification, c'est le coup à avoir zéro.

Si si, le module TI-Python vendu supposément pour améliorer ta TI-83PCE la fait régresser en calcul !

Et encore, j'ai choisi un exemple non effrayant.
Mettez un seuil à peine inférieur de 0.01, et là le TI-Python répond 7011, alors que le résultat attendu est 6365 !

Je dirais même qu'il est dangereux d'utiliser le module TI-Python au BAC pour les questions d'algorithmique sur des suites récurrentes...
et le pire c'est que c'est le contexte d'un bon 90% des questions d'algorithmique qui tombent au BAC !

[Lionel Debroux]

Tu leur avais pourtant signalé cette vraie, grosse limitation. Mais vu qu'ils ont choisi un SoC anémique pour gagner peut-être deux dollars par TI-Python Adapter, leur marge de manoeuvre pour mettre des flottants double précision semble plutôt réduite.

[critor]

Pour sortir du cadre (évident... sauf apparemment pour ceux qui ont fait le mauvais choix de CircuitPython) des suites numériques définies par récurrence.

Polynômes du second degré :

Code: Select all

from math import *
def roots(a,b,c):
  delta=b*b-4*a*c
  if abs(delta)==0:
    return -b/(2*a)
  elif delta>0:
    x1=(-b-sqrt(delta))/(2*a)
    x2=(-b+sqrt(delta))/(2*a)
    return x1,x2
  else:
    return None

Dans des cas où toutes les pythonnettes trouvent bien un discriminant positif et renvoient la même paire de solutions, que ce soit en Python ou dans leur langage interprété historique...


... et bien non. Bien que les deux solutions restent différentes même en ne retenant que les seuls 6 premiers chiffres significatifs gérés par le TI-Python, ce dernier dit quand même que l'on est dans le cas où le discriminant est nul et qu'il n'y a qu'une seule solution :

>>> roots(1,2.0000001,1)
-1.0

Faire confiance à un programme de 2nd degré écrit en Python sur TI-83 Premium CE, même après l'avoir soigné pour qu'il donne le raisonnement, la rédaction et tout, c'est risquer là aussi d'avoir tout faux.

[critor]

Simple algo itératif de calcul de somme :

Code: Select all

def sriemann(k,a,b,d):
  s=0
  for i in range(a,b+d,d):
    s+=1/i**k
  return s

Notons d'ailleurs, accessoirement, qu'avec les flottants la somme n'est pas commutative. Selon que l'on somme dans un sens ou dans l'autre, pas exactement le même résultat :


Avec le TI-Python, une erreur très grossière d'arrondi dès le 4ème chiffre après la virgule dans l'un des deux cas, ça commence à être limite sur une copie...

>>> sriemann(2,1,10000,1)
1.64405
>>> sriemann(2,10000,1,-1)
1.64483

On n'est pas encore à 5% d'erreur certes, mais le correcteur va commencer à se demander sérieusement avoir quoi tu calcules...

[critor]

Et en passant, bien évidemment, les entiers ne sont pas mieux gérés que les flottants :

>>> sriemann(2,1,100000,1)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "sriemann.py", line 4, in sriemann
OverflowError: small int overflow

[critor]

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

Code: Select all

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 :

On peut donc conjecturer en toute confiance que pour f(x)=x³, f'(1)=3 et f''(1)=6.

Sur le TI-Python, c'est une autre histoire...

>>> table(f,1,7)
1 7.0 12.0
0.1 3.30999 6.60005
0.01 3.02997 6.07967
0.001 3.00264 5.72205
0.0001 2.98977 143.051
1e-05 3.00407 0.0
1e-06 2.86102 0.0

A aucun moment il ne permet de conjecturer ça tellement les différences sont importantes d'une ligne à l'autre...
Pire encore, à la 4ème itération au lieu de s'améliorer la dérivée seconde empire, pour devenir même aberrante dès la 5ème itération .
Et à la 7ème itération, c'est au tour de la dérivée première de se mettre à délirer elle aussi.

[critor]

Suite récurrente d'ordre 2, Terminale S Spécialité Mathématiques.

Code: Select all

from math import *

def u(n):
  k=0
  uc=1
  un=1-sqrt(2)
  for k in range(n):
    t=2*un+uc
    uc=un
    un=t
  return uc

def table(u,n):
  for i in range(n):
    print(i,u(i))

ça se voit que cette suite converge vers 0 sans monotonie, non ?...


... mais pas sur le TI-Python, où la suite amorce une divergence croissante vers l'infini dès le rang 10 !

>>> table(u,23)
0 1
1 -0.414213
2 0.171574
3 -0.0710659
4 0.0294418
5 -0.0121822
6 0.00507736
7 -0.00202751
8 0.00102234
9 1.71661e-05
10 0.00105667
11 0.00213051
12 0.00531769
13 0.0127659
14 0.0308495
15 0.0744648
16 0.179779
17 0.434023
18 1.04782
19 2.52967
20 6.10717
21 14.744
22 35.5952

[Lionel Debroux]

On peut tenter, à notre niveau, de communiquer sur le fait que le TI-Python Adapter est inutilisable pour un certain nombre de problèmes représentatifs de niveau lycée... mais la majorité des lycéens ne nous lit pas, bien entendu


De mon côté, j'ai essayé de trafiquer un peu plus CircuitPython pour activer au moins les modules math et urandom dans mon build pour Trinket M0, ça passe encore dans la quantité limitée de Flash
J'ai aussi activé cmath, mais vu que la taille du binaire soi-disant avec cmath est la même que la taille du binaire sans, il y a manifestement un autre problème que je n'ai pas le temps de debugger maintenant...
Ca serait super si quelqu'un pouvait tester sur sa Trinket M0... à ses risques et périls, bien sûr, mais je ne vois pas pourquoi ça pourrait endommager la carte plus, ou moins, qu'un build CircuitPython single FP

[Adriweb]

De mon côté, j'ai essayé de trafiquer un peu plus CircuitPython pour activer au moins les modules math et urandom dans mon build pour Trinket M0, ça passe encore dans la quantité limitée de Flash
J'ai aussi activé cmath, mais vu que la taille du binaire soi-disant avec cmath est la même que la taille du binaire sans, il y a manifestement un autre problème que je n'ai pas le temps de debugger maintenant...
Ca serait super si quelqu'un pouvait tester sur sa Trinket M0... à ses risques et périls, bien sûr, mais je ne vois pas pourquoi ça pourrait endommager la carte plus, ou moins, qu'un build CircuitPython single FP

Presque?

[Lionel Debroux]

Quoi, ce n'est pas ça le résultat ?
Merci pour tes tests... au moins on sait que ça boote mais que ça calcule n'importe quoi.
Si quelqu'un est intéressé, il va falloir qu'il/elle fasse le debug tout(e) seul(e), parce que je n'ai ni Trinket M0, ni JTAG.