BAC S 2019 Amérique Nord plante toutes calcs sauf NumWorks
Posted: 29 May 2019, 16:48
Ce mardi, c'était l'épreuve de Mathématiques du BAC S 2019 en Amérique du Nord.Petite particularité dans l'exercice 3 sur une suite positive d'écroissante définie par récurrence. En avant-dernière question B.4.a, pour une fois il n'était pas demandé d'interpréter, modifier ou compléter un algorithme, mais d'en écrire un intégralement. Un algorithme de seuil, retournant à partir de quel rang les termes de la suite passent en-dessous de 10-p.
Pour référence, voici l'algorithme en question transcrit en Python :
- Code: Select all
from math import *
def algo(p):
n=0
u=1.
while u>10**-p:
u=u-log(1+u)
n=n+1
print(n,u)
return n
La question suivante B.4.b et dernière en était l'application, demandant la réponse de l'algorithme pour p=15. Heureusement cela pouvait être obtenu sans algorithme pour ceux qui avaient bloqué sur la question précédente.
Pour référence, avec
$mathjax$u_5\approx 3,95\times 10^{-14}$mathjax$
et $mathjax$u_6\approx 7,80\times 10^{-28}$mathjax$
, la réponse attendue est n=6.Cela n'a peut-être l'air de rien mais ce fut en pratique une hécatombe pour nos calculatrices graphiques et programmables, puisque la quasi totalité a soit donné des résultats aberrants, soit n'a retourné aucun résultat partant alors en boucle infinie, et ce que l'on code l'algorithme ou utilise l'application dédiée aux suites ! 
Que l'outil calculatrice ait été utilisé pour chercher ou confirmer le résultat, de quoi gaspiller dans tous les cas de précieuses minutes à chercher en vain ce qui peut bien clocher !
Les Casio Graph programmées dans leur langage historique ne renvoyaient jamais de réponse, partant en boucle infinie. Le problème est visualisable dans l'application Récurrence, la suite devenant stationnaire à partir du rang n=5 sans avoir atteint le seuil souhaité. Pareil si tu utilisais l'application KhiCAS sur Graph 90+E ou sur Graph 35+E II. Pareil également sur fx-CP400, fx-92+ Spéciale Collège ou encore Lexibook GC3000FR.
Par contre, pas de problème si tu codais l'algorithme avec l'application Python intégrée aux Graph 90+E et Graph 35+E II, ou avec l'application CasioPython rajoutée...
Les TI-82/83/84 programmées dans leur langage historique renvoyaient un résultat faux, n=5. Le tableau de valeurs de la suite nous permet là encore de comprendre ce qui se passe, la suite devient stationnaire à partir du rang n=5 en franchissant le seuil demandé, mais avec une valeur aberrante puisque négative alors que nous sommes sur une suite positive selon les questions précédentes.
Par contre, aucun problème si tu codais l'algorithme pour le module externe TI-Python via l'application PyAdaptr de la TI-83 Premium CE...
Sur la HP Prime programmée dans son langage historique, pareil on obtient n=5. L'application Suite permet de constater le problème, avec une première valeur négative aberrante au rang 5 avant que la suite ne devienne stationnaire.
Par contre, aucun problème si tu codais l'algorithme en utilisant l'étiquette
Sur TI-Nspire programmée dans son langage historique on obtient par chance n=6, juste parce que la première valeur aberrante négative est bien tombée. Le problème est là encore visualisable avec le tableau de valeurs de la suite.
Par contre, aucun problème du tout si tu codais l'algorithme pour l'application MicroPython...
Mais qu'est-ce que c'est que ça, un sujet sponsorisé NumWorks / Python ?...
Que l'outil calculatrice ait été utilisé pour chercher ou confirmer le résultat, de quoi gaspiller dans tous les cas de précieuses minutes à chercher en vain ce qui peut bien clocher !
Les Casio Graph programmées dans leur langage historique ne renvoyaient jamais de réponse, partant en boucle infinie. Le problème est visualisable dans l'application Récurrence, la suite devenant stationnaire à partir du rang n=5 sans avoir atteint le seuil souhaité. Pareil si tu utilisais l'application KhiCAS sur Graph 90+E ou sur Graph 35+E II. Pareil également sur fx-CP400, fx-92+ Spéciale Collège ou encore Lexibook GC3000FR. Par contre, pas de problème si tu codais l'algorithme avec l'application Python intégrée aux Graph 90+E et Graph 35+E II, ou avec l'application CasioPython rajoutée...
Les TI-82/83/84 programmées dans leur langage historique renvoyaient un résultat faux, n=5. Le tableau de valeurs de la suite nous permet là encore de comprendre ce qui se passe, la suite devient stationnaire à partir du rang n=5 en franchissant le seuil demandé, mais avec une valeur aberrante puisque négative alors que nous sommes sur une suite positive selon les questions précédentes. Par contre, aucun problème si tu codais l'algorithme pour le module externe TI-Python via l'application PyAdaptr de la TI-83 Premium CE...
Sur la HP Prime programmée dans son langage historique, pareil on obtient n=5. L'application Suite permet de constater le problème, avec une première valeur négative aberrante au rang 5 avant que la suite ne devienne stationnaire. Par contre, aucun problème si tu codais l'algorithme en utilisant l'étiquette
#cas indiquant à l'interpréteur d'utiliser le moteur CAS pour les calculs, étiquette d'ailleurs obligatoire si tu décidais d'opter pour l'écriture à la Python...
Sur TI-Nspire programmée dans son langage historique on obtient par chance n=6, juste parce que la première valeur aberrante négative est bien tombée. Le problème est là encore visualisable avec le tableau de valeurs de la suite. Par contre, aucun problème du tout si tu codais l'algorithme pour l'application MicroPython...
Mais qu'est-ce que c'est que ça, un sujet sponsorisé NumWorks / Python ?...
Pour comprendre un peu mieux ce qui se passe, rappelons que pour les nombres non entiers nos calculatrices travaillent en virgule flottante, soit au format
Or, toutes les calculatrices n'accordent pas le même nombre de bits pour coder la mantisse M de ces nombres, ce qui limite leur nombre de chiffres significatifs.
C'est-à-dire que pour tout calcul donnant un résultat non décimal, notre calculatrice commet une petite erreur. Et lorsque l'on réutilise ce résultat dans un nouveau calcul, comme c'est notamment le cas dans le cadre d'algorithmes sur des suites définies par récurrence, il peut arriver que cela empire l'erreur, jusqu'à donner des résultats aberrants...
Voici la transcription en Python d'un algorithme permettant de calculer les nombres de bits et de chiffres significatifs utilisables pour les mantisses de flottants, ceci en appelant respectivement
Précisons que selon les modèles de calculatrices, le test devra être réalisé deux fois, car bien souvent l'environnement Python utilisera un moteur de calcul spécifique totalement déconnecté du reste de l'écosystème de la calculatrice.
Voici le petit classement de différents modèles/configurations en termes de précision binaire et décimale qui en découle, où nous allons de plus indiquer en rouge lorsque cela ne permet pas de répondre correctement au sujet qui nous intéresse ici :
Voilà donc l'explication, ça semble clair, c'est un problème de précision. Les modèles/configurations qui calculent sur 45 bits et moins sont incapables de fournir une réponse correcte. Hors la plupart des modèles ne dépassent pas les 40 bits dans le contexte de leur moteur de calcul historique.
A partir de 48 bits et plus, c'est bon. Les implémentations Python pour nos calculatrices utilisent presque toutes pour la mantisse le standard à 53 bits dit en "double précision", ce qui explique qu'elles ne soient pas concernées par le problème.
La NumWorks est un cas particulier puisque même en dehors de son application Python et donc limitée à 45 bits, elle trouve des valeurs cohérentes et fournit ainsi le bon résultat. Peut-être que cela vient du fait que la calculatrice n'évalue pas directement les expressions sur 45 bits, mais commence par faire appel à son moteur de calcul littéral intégré, et ce même lorsque l'on fait intervenir des nombres en écriture décimale.
$mathjax$\pm M\times 2^{E-E_{min}}$mathjax$
avec $mathjax$M\in [1;2[$mathjax$
.Or, toutes les calculatrices n'accordent pas le même nombre de bits pour coder la mantisse M de ces nombres, ce qui limite leur nombre de chiffres significatifs.
C'est-à-dire que pour tout calcul donnant un résultat non décimal, notre calculatrice commet une petite erreur. Et lorsque l'on réutilise ce résultat dans un nouveau calcul, comme c'est notamment le cas dans le cadre d'algorithmes sur des suites définies par récurrence, il peut arriver que cela empire l'erreur, jusqu'à donner des résultats aberrants...
Voici la transcription en Python d'un algorithme permettant de calculer les nombres de bits et de chiffres significatifs utilisables pour les mantisses de flottants, ceci en appelant respectivement
precm(2) et precm(10) :- Code: Select all
def precm(b):
k,b=0,float(b)
while 1+b**-k-1>0:
k+=1
return k
Précisons que selon les modèles de calculatrices, le test devra être réalisé deux fois, car bien souvent l'environnement Python utilisera un moteur de calcul spécifique totalement déconnecté du reste de l'écosystème de la calculatrice.
Voici le petit classement de différents modèles/configurations en termes de précision binaire et décimale qui en découle, où nous allons de plus indiquer en rouge lorsque cela ne permet pas de répondre correctement au sujet qui nous intéresse ici :
| modèles | bits | chiffres significatifs |
| Graph 90+E / fx-CG50 (appli Python) Graph 35+E II (appli Python) Graph 35/75/85/95 USB / fx-9750GII/9860G (appli CasioPython) NumWorks (appli Python) TI-83 Premium CE Edition Python (appli Python) TI-83 Premium CE (module externe TI-Python) TI-Nspire (appli MicroPython) | 53 | 16 |
| HP Prime (vue CAS) | 48 | 15 |
| NumWorks (hors appli Python) Graph 90+E / fx-CG10/20/50 (appli KhiCAS) Graph 35+E II (appli KhiCAS) TI-82/85/86/89/92 / Voyage 200 TI-Nspire (hors appli MicroPython) | 45 | 14 |
| TI-81 | 41 | 13 |
| fx-92 Collège 2D / Spéciale Collège / fx-ES/EX Graph 90+E / fx-CG50 (hors applis Python/KhiCAS) Graph 35/75/85/95 USB / fx-9750GII/9860G (hors appli CasioPython et KhiCAS) fx-CG10/20 (hors appli KhiCAS) Sharp EL-9900/9950 TI-83 Premium CE Edition Python (hors appli Python) TI-83 Premium CE (sans module externe TI-Python) TI-83 / TI-83 Plus TI-82 Stats/Plus/Advanced TI-73/76.fr/84 | 40 | 13 |
| HP Prime (hors vue CAS) | 38 | 12 |
| Lexibook GC3000FR | 35 | 11 |
| TI-Primaire Plus | 34 | 11 |
| TI-Collège Plus / 30/34/36 MultiView | 32 | 10 |
| fx-CP400/CG500 / Classpad | 31 | 10 |
Voilà donc l'explication, ça semble clair, c'est un problème de précision. Les modèles/configurations qui calculent sur 45 bits et moins sont incapables de fournir une réponse correcte. Hors la plupart des modèles ne dépassent pas les 40 bits dans le contexte de leur moteur de calcul historique.
A partir de 48 bits et plus, c'est bon. Les implémentations Python pour nos calculatrices utilisent presque toutes pour la mantisse le standard à 53 bits dit en "double précision", ce qui explique qu'elles ne soient pas concernées par le problème.
La NumWorks est un cas particulier puisque même en dehors de son application Python et donc limitée à 45 bits, elle trouve des valeurs cohérentes et fournit ainsi le bon résultat. Peut-être que cela vient du fait que la calculatrice n'évalue pas directement les expressions sur 45 bits, mais commence par faire appel à son moteur de calcul littéral intégré, et ce même lorsque l'on fait intervenir des nombres en écriture décimale.
Il est certes déjà arrivé que certains sujets de BAC posent des questions qui dérangent nos calculatrices, mais uniquement dans le cadre d'une conjecture et pour enchaîner ensuite sur une série de questions qui vont démontrer que la calculatrice s'est trompée, ce qui en sera la conclusion.
Ce n'est clairement pas le cas ici puisqu'il s'agit de la dernière question de l'exercice. C'est donc une grave erreur de l'auteur du sujet qui sans doute n'a pas fait l'effort de tester son énoncé avec une calculatrice 'normale' comme celles dont disposent la majorité des candidats, mais avec la NumWorks ou plus probablement directement dans l'environnement Python de son ordinateur. Grave erreur de ne pas avoir pensé aux différences que cela impliquait au niveau du moteur de calcul numérique !
A la décharge de l'auteur du sujet, le fait que l'institution pousse à fond au Python à tous les étages.
Les candidats ici équipés en calculatrices NumWorks ont donc été avantagés, ainsi que la minorité qui a utilisé le Python sur un autre modèle pour résoudre l'exercice.
Même si l'on doit pouvoir trouver des candidats passionnés par le Python, ainsi que des enseignants de Terminale qui n'ont fait travailler que le Python cette année, rappelons que le premier programme imposant officiellement le Python n'est arrivé que pour la rentrée 2017 en Seconde. Il s'agit donc probablement d'une minorité qui a ainsi été privilégiée (ce qui ne veut absolument pas dire que c'est moins grave). Les candidats au BAC 2019 n'auraient jamais dû être ainsi discriminés selon leur affinité avec le Python puisque ce langage n'était pas une exigence des textes les concernant.
Ce qui est à craindre c'est que ce cafouillage ne soit pas isolé, et que d'autres sujets à venir n'aient été testés qu'en Python sur l'ordinateur des auteurs. Dans ton intérêt nous ne pouvons donc que te conseiller si tu ne l'as pas déjà fait d'opter sans attendre pour une configuration conforme aux nouveaux programmes du lycée et donc aux habitudes des concepteurs de sujets, et de prendre l'habitude de coder tes algorithmes systématiquement en Python et non plus dans le langage historique de ta calculatrice.
Des solutions qui ne te coûteront pas le moindre centime existent :
Que tu ne rentres pas dans les cas ci-dessus ou que tu aies peur de te lancer dans des manipulations à la veille de l'examen, voici maintenant les solutions nécessitant un achat, limitées aux plus pertinentes et aux moins chères :
Ce n'est clairement pas le cas ici puisqu'il s'agit de la dernière question de l'exercice. C'est donc une grave erreur de l'auteur du sujet qui sans doute n'a pas fait l'effort de tester son énoncé avec une calculatrice 'normale' comme celles dont disposent la majorité des candidats, mais avec la NumWorks ou plus probablement directement dans l'environnement Python de son ordinateur. Grave erreur de ne pas avoir pensé aux différences que cela impliquait au niveau du moteur de calcul numérique !
A la décharge de l'auteur du sujet, le fait que l'institution pousse à fond au Python à tous les étages.
Les candidats ici équipés en calculatrices NumWorks ont donc été avantagés, ainsi que la minorité qui a utilisé le Python sur un autre modèle pour résoudre l'exercice.
Même si l'on doit pouvoir trouver des candidats passionnés par le Python, ainsi que des enseignants de Terminale qui n'ont fait travailler que le Python cette année, rappelons que le premier programme imposant officiellement le Python n'est arrivé que pour la rentrée 2017 en Seconde. Il s'agit donc probablement d'une minorité qui a ainsi été privilégiée (ce qui ne veut absolument pas dire que c'est moins grave). Les candidats au BAC 2019 n'auraient jamais dû être ainsi discriminés selon leur affinité avec le Python puisque ce langage n'était pas une exigence des textes les concernant.
Ce qui est à craindre c'est que ce cafouillage ne soit pas isolé, et que d'autres sujets à venir n'aient été testés qu'en Python sur l'ordinateur des auteurs. Dans ton intérêt nous ne pouvons donc que te conseiller si tu ne l'as pas déjà fait d'opter sans attendre pour une configuration conforme aux nouveaux programmes du lycée et donc aux habitudes des concepteurs de sujets, et de prendre l'habitude de coder tes algorithmes systématiquement en Python et non plus dans le langage historique de ta calculatrice.
Des solutions qui ne te coûteront pas le moindre centime existent :
Mises à jour logicielles gratuites :
Si tu as une Casio Graph 90+E / fx-CG50, mets-la à jour en version 3.20 et utilise dorénavant l'application Python intégrée pour coder :
- logiciel de mise à jour Graph 90+E 3.20 pour Windows
- logiciel de mise à jour Graph 90+E 3.20 pour Mac
Si tu as une Casio Graph 35+E II, mets-la à jour en version 3.10 et utilise dorénavant l'application Python intégrée pour coder :
logiciel de mise à jour Graph 35+E II 3.10 pour Windows
Si tu as une Casio Graph 75/85/95, installe et utilise l'application CasioPython.
Si tu as une Casio Graph 35+, installe-lui le système Graph 75 2.05, puis procède comme au point précédent.
Si tu as une TI-Nspire, installe Ndless, puis installe et utilise l'application MicroPython.
Si tu as une HP Prime, mets-la à jour en version 14181 et code désormais en cochant toujours CAS :
- logiciel de mise à jour 2.1.14181 pour Windows 64 bits
- logiciel de mise à jour 2.1.14181 pour Windows 32 bits
- logiciel de mise à jour 2.1.14181 pour Mac
Si tu as une Lexibook GC3000FR jette-la par la fenêtre plutôt que de recopier ce qu'elle peut bien te raconter, c'est gratuit et c'est dans ton intérêt.
Que tu ne rentres pas dans les cas ci-dessus ou que tu aies peur de te lancer dans des manipulations à la veille de l'examen, voici maintenant les solutions nécessitant un achat, limitées aux plus pertinentes et aux moins chères :
Mises à jour matérielles payantes :
Si tu as la TI-83 Premium CE, rajoute-lui le module externe TI-Python qui ne coûte vraiment pas grand chose et installe l'application PyAdaptr associée :
- http://boutique.jarrety.fr/accessoires-calculatrices/59-chargeur-murale-pour-nspire-cas.html
- https://www.boutique-calculatrice-ti.com/accessoires-texas-instruments/58-module-python-externe-pour-ti-83-premium-ce.html
Si tu as une TI-82/84 ou autre TI-83, il te faut une TI-83 Premium CE. Aucun problème de prise en main, tu y retrouveras les mêmes touches, menus et interfaces. Tu peux au choix prendre :
- une TI-83 Premium CE avec le module externe TI-Python
- ou la TI-83 Premium CE Edition Python qui devrait être disponible ce mois-ci - mais le sera-t-elle à temps ?...
Si tu as une TI-Nspire CX II, remplace-la par un ancien modèle TI-Nspire CX, TI-Nspire CM ou TI-Nspire monochrome puis procède comme au bloc précédent.
Si tu as une Casio Graph 25+/35+, remplace-la au choix par une Graph 75/85/95 puis procède comme au bloc précédent. Aucun problème de prise en main, mêmes touches, menus et interfaces.
Si tu as la Casio Graph 35+E, la Graph 35+USB ou une Graph 25/75/85/95, remplace-la au choix par :
- une Graph 35+E II si déjà disponible, sur laquelle Casio te rembousera 10€
- une Graph 90+E
Si tu as une Casio fx-CG10/20, remplace-la par une Graph 90+E. Prise en main immédiate puisque mêmes touches, menus et interfaces.
Ou sinon suis le message que fait passer (involontairement ?...) l'auteur du sujet et achète une NumWorks, même si selon nous un changement pour un modèle au fonctionnement complètement différent à la veille de l'examen n'est pas une bonne idée.
Téléchargement : sujet et corrigés