Sortie/test TI-Nspire CX II 5.2 Python + QCC 2020 épilogue

[critor]

Donc, il y avait en version 5.2 un bug avec le module Python ti_image, traité dans l'article et que je rappelle ici.

Lorsque l'on insère une ressource image dans un document .tns via l'éditeur de script Lua :

• l'image est affichée correctement par un script Lua
• mais l'image est affichée à l'envers par un script Python, et parfois pire avec une distorsion horizontale

Espérons que ce sera enfin corrigé pour la version 5.3, mise à jour annuelle à venir d'ici la rentrée 2021 je suppose.



Autre bug découvert ces derniers jours et ici majeur, puisque pouvant à la différence impacter un très large éventail de scripts.
La fonction round() génère une exception si :

• on lui demande d'arrondir un nombre entier
• tout en précisant le nombre de décimales souhaitées

Bien sûr aucun intérêt à arrondir un entier, mais dans le contexte d'un script, il est parfaitement possible de temps en temps que les valeurs traitées soient entières.
Personnellement, je m'en suis rendu compte en intégrant un turtle.py à certains de mes documents .tns, script qui fonctionnait parfaitement sur d'autres plateformes. Certains mouvements de la tortue généraient donc une exception, lorsque les valeurs géométriques calculées en interne étaient donc entières.

Le bug n'est pas présent sur les TI-83PCE/84+CE ni sur les modèles concurrents, ces derniers n'ont aucune difficulté à arrondir.

C'est embarrassant ca...

Mais bon en attendant ce n'est pas compliqué de se créer un "wrapper":

Code: Select all

round_ = round

def is_integer_num(n):
    if isinstance(n, int):
        return True
    if isinstance(n, float):
        return n.is_integer()
    return False

def round(n, p):
  return n if is_integer_num(n) else round(n, p)


... ou un truc dans ce genre (pas testé)

Merci.
À intégrer donc en début de chaque script Python TI-Nspire CX II utilisant round().

[Lionel Debroux]

Embarrassant, le mot est faible. Une fonction round() qui ne fonctionne pas, sérieusement...

[critor]

Autre bug découvert ces derniers jours et ici majeur, puisque pouvant à la différence impacter un très large éventail de scripts.
La fonction round() génère une exception si :

• on lui demande d'arrondir un nombre entier
• tout en précisant le nombre de décimales souhaitées

Bien sûr aucun intérêt à arrondir un entier, mais dans le contexte d'un script, il est parfaitement possible de temps en temps que les valeurs traitées soient entières.
Personnellement, je m'en suis rendu compte en intégrant un turtle.py à certains de mes documents .tns, script qui fonctionnait parfaitement sur d'autres plateformes. Certains mouvements de la tortue généraient donc une exception, lorsque les valeurs géométriques calculées en interne étaient donc entières.

Le bug n'est pas présent sur les TI-83PCE/84+CE ni sur les modèles concurrents, ces derniers n'ont aucune difficulté à arrondir.

C'est embarrassant ca...

Mais bon en attendant ce n'est pas compliqué de se créer un "wrapper":

Code: Select all

round_ = round

def is_integer_num(n):
    if isinstance(n, int):
        return True
    if isinstance(n, float):
        return n.is_integer()
    return False

def round(n, p):
  return n if is_integer_num(n) else round(n, p)


... ou un truc dans ce genre (pas testé)

Peut-être ai-je manque de clareté, désolé.

Le bug de la fonction round() concerne uniquement le type entier.
Elle n'a aucun problème avec les flottants de valeur entière.

Donc on peut simplifier le correctif :

Code: Select all

round_ = round

def round(n, p=0):
  return n if isinstance(n, int) else round_(n, p)

[Adriweb]

Ah ben oui, en effet

[cent20]

Ce n'est pas plus simple ça :

Code: Select all

round_ = round

def round(n, p):
  return n if n == int(n) else round_(n, p)


[Bisam]

isinstance(n, int) est bien plus général et ne renverra pas d'erreur si la fonction int ne s'applique pas à son type, par exemple si n est une liste.
Par ailleurs, la méthode est plus efficace puisque elle va se contenter de vérifier le type de la variable, sans se préoccuper de sa valeur ni faire de calcul ou de test avec cette valeur. C'est un gain particulièrement substantiel si n est un très grand entier.

Code: Select all

import time

def test1(essais = 10000000):
    n = 3**51361 - 1
    deb = time.monotonic()
    for _ in range(essais):
        n == int(n)
    return time.monotonic() - deb

def test2(essais = 10000000):
    n = 3**51361 - 1
    deb = time.monotonic()
    for _ in range(essais):
        isinstance(n, int)
    return time.monotonic() - deb

L'entier n choisi a été pris au hasard dans le seul but d'être grand et pas trop facilement représentable en binaire.

Si on lance "test1()" avec 10 millions d'essais, cela s'effectue en 1,1s environ.
Si on lance "test2()" avec 10 millions d'essais, cela s'effectue en 0,7s environ, soit un gain d'environ 40%.

[cent20]

isinstance(n, int) est bien plus général et ne renverra pas d'erreur si la fonction int ne s'applique pas à son type, par exemple si n est une liste.

Hum ... La fonction round() n'est pas prévue pour gérer des listes il me semble.

round(number[, ndigits])

Par ailleurs, la méthode est plus efficace puisque elle va se contenter de vérifier le type de la variable, sans se préoccuper de sa valeur ni faire de calcul ou de test avec cette valeur. C'est un gain particulièrement substantiel si n est un très grand entier.

Code: Select all

import time

def test1(essais = 10000000):
    n = 3**51361 - 1
    deb = time.monotonic()
    for _ in range(essais):
        n == int(n)
    return time.monotonic() - deb

def test2(essais = 10000000):
    n = 3**51361 - 1
    deb = time.monotonic()
    for _ in range(essais):
        isinstance(n, int)
    return time.monotonic() - deb

L'entier n choisi a été pris au hasard dans le seul but d'être grand et pas trop facilement représentable en binaire.

Si on lance "test1()" avec 10 millions d'essais, cela s'effectue en 1,1s environ.
Si on lance "test2()" avec 10 millions d'essais, cela s'effectue en 0,7s environ, soit un gain d'environ 40%.

Je note donc que le code avec le test n == int(n) est 40% moins efficace

>>> test1()
1.875
>>> test2()
1.281

par contre tu tords un peu le comparatif avec ton n = 3**51361 - 1 ... et tu oublies d'appeler les fonctions intermédiaires d'Adrien.

EDIT1 : Je viens de refaire le test avec n=42 ou n=666 il y a toujours les 40% d'écart, il n'était donc pas nécessaire de chercher le diable avec 3**51361 - 1

EDIT2 : Je viens de faire le test avec l'intégralité des fonctions, il y a toujours cet écart de 40%.

Je prend donc note que je mon code est pas optimisé, ceci dit je n'en suis pas encore là dans mon autoformation à partir de 0...

Ah sinon, j'ai testé sur une NumWorks, tout fonctionne bien.
Il suffit donc de prendre une NumWorks, je suis sur qu'en plus elle est plus rapide que la Nspire d'au moins 42% !

[cent20]

Et fait j'ai fait un quiproquo tout seul... Ma réponse "ce n'est pas plus simple ça" c'était par rapport au code d'Adrien, je n'avais pas lu le message trop long de critor ... et il contenait une version en 3 lignes...

Je parlais donc de la simplicité en terme de longueur, mais je n'avais aucune idée de l'efficacité ou non du code, merci Bisam pour ces précisions.

[critor]

Tiens, autre problème qui semble avoir été introduit en version 5.1 ou 5.2 (comme je ne peux pas downgrader et que je n'ai pas d'émulateur, je ne sais pas exactement), une erreur de traduction qui rend l'interface d'activation du mode examen incompréhensible en Français.

En anglais le moteur CAS peut-être mis à On / Off, ce qui en version 5.0 était initialement traduit en Activé / Désactivé.
En version 5.2, la traduction du On en Activé a été remplacée par Sur !


Même problème sur la TI-Nspire CX II-T pour la désactivation ou pas du moteur de calcul exact :


Cela pourrait être mal compris par certains candidats, qui plus est un jour d'épreuves...

[Afyu]

Parce que "on" peut se traduire par "sur". Et visiblement, ils n'ont pas vérifié leur traduction.