QCC 2017 épisode 22 : Programmation

[Adriweb]

Attention, les programmes evoluent. Si on se refere au nouveau document ressource, il y aura des variables avec des noms a plusieurs lettres

Certes - j'avais en tête les sujets d'encore aujourd'hui. Après... on verra en pratique ce que ça va donner. Pour du python on autre, c'est sûr que ça paraît obligé.

des fonctions qui prennent en argument d'autres fonctions, ce qui sauf erreur de ma part, n'est possible sur calculatrices en builtin que sur la Prime en programmation CAS.

En théorie, avec expr() (donc la fonction passé en string, pas directement), aucun soucis sur Nspire pour autant que je sache

[parisse]

c'est la partie 4 : viewtopic.php?f=49&t=20349#QCC224
sur la Prime il faut mettre la programmation CAS pour pouvoir faire cette partie?

Oui et non. Le langage non CAS de la Prime (ou celui de la nspire ou du classpad) permet de definir des fonctions, ce qu'il ne permet pas c'est de passer une fonction en argument, par exemple si on ecrit une fonction pour determiner une racine de f(x)=0 par dichotomie, on adoptera un prototype du genre

Code: Select all

dicho(f,a,b,eps)

ou on passe la fonction f en argument. Dans ce cas, on peut contourner cette limitation en passant une expression au lieu d'une fonction, i.e. on passe l'expression ex:=f(x) au lieu de f en argument, et dans le corps de la fonction dicho on ecrit ex|x=a au lieu de f(a) (ou on utilise la methode proposee par Adriweb, mais elle est moins naturelle et plus couteuse en temps a cause de l'appel a expr).

[critor]

Merci pour toutes ces précisions.

On va voir si cela se concrétise dans les nouveaux programmes de Première/Terminale...

Nous avons bien dit aux deux constructeurs TI/Casio qu'il fallait absolument Python sur leurs machines, qu'il n'était pas possible de 'bricoler' les langages actuels tellement ils sont différents.
(sauf peut-être le langage Nspire, mais les ventes me semblant être en net recul en France depuis le lancement de la 83PCE vu que plus grand monde ne demande d'aide pour les Nspire sur notre forum à part encore les anglophones, à mon avis ce ne sera pas une priorité)

[parisse]

Je ne suis pas de cet avis. Je pense d'une part que le programme est trop ambitieux, en tout cas tel qu'il est decline dans le document ressource (les profs ne vont pas passer miraculeusement d'algobox a ca) et d'autre part que ce serait une erreur de n'utiliser que Python comme langage au lycee, les langages des nspire, classpad et prime (en mode CAS ou non) conviennent a mon avis aussi bien, sinon mieux car permettant d'integrer l'enseignement au cours de maths. C'est marrant comme en informatique il se forme plus qu'ailleurs des lobbies qui defendent corps et ames un langage ou un modele ou un os, sans souvent d'ailleurs avoir le recul scientifique suffisant pour bien juger, mais simplement la position hierarchique pour imposer.

[Adriweb]

Je ne suis pas de cet avis. Je pense d'une part que le programme est trop ambitieux, en tout cas tel qu'il est decline dans le document ressource (les profs ne vont pas passer miraculeusement d'algobox a ca) et d'autre part que ce serait une erreur de n'utiliser que Python comme langage au lycee, les langages des nspire, classpad et prime (en mode CAS ou non) conviennent a mon avis aussi bien, sinon mieux car permettant d'integrer l'enseignement au cours de maths. C'est marrant comme en informatique il se forme plus qu'ailleurs des lobbies qui defendent corps et ames un langage ou un modele ou un os, sans souvent d'ailleurs avoir le recul scientifique suffisant pour bien juger, mais simplement la position hierarchique pour imposer.

En effet, les décideurs la haut (v)ont probablement imposé le Python officieusement... mais bref, par rapport à ce qu'on a envoyé à TI, par rapport à la CE (on imaginant en effet que le Basic-Nspire soit déjà conforme, et c'est pour ça que ça n'a pas été le sujet de discussion - critor pensait sans doute implicitement à ça) :
Le document que l'on a rédigé fait plusieurs pages, et après analyse du texte du gouvernement, des situations actuelles et futures potentielles etc., donne des propositions d'améliorations, et bref voici un bout de la conclusion (pour la plateforme CE, je rappelle bien) :

Pour pouvoir proposer une solution rapidement [...]: pouvoir créer ses propres fonctions/commandes, comme certaines présentes dans le catalogue : elles ont un ou plusieurs arguments, et peuvent retourner une valeur.

A moyen et long terme (un an et plus), la prise en compte de l’ensemble du nouveau programme de Seconde et de ce qui en découlera logiquement implique une refonte assez majeure du TI-Basic 83PCE / 84+CE si on veut que ce soit fait correctement.

Ainsi, il serait donc très important, à notre sens, de simplement avoir autre chose, en plus du TI-Basic existant, assez rapidement (moins de 2 ans, idéalement 1 an). Cet autre chose pourrait parfaitement se présenter sous forme de FlashApp optionnelle, par ailleurs.

Voici trois idées, qui ne sont du reste pas nouvelles, remplissant les principaux critères requis par le programme de l’Education Nationale :

• Une implémentation légère du langage Python, telle que MicroPython (déjà porté de façon non officielle sur Nspire, avec un faible effort de développement), conviendrait majoritairement du point de vue des professeurs et de l'institution, favorisant déjà ce langage.
• Une implémentation du langage Lua, autre choix au moins aussi facile à mettre en oeuvre techniquement que MicroPython. Lua est suffisamment petit et rapide pour pouvoir bien fonctionner sur CE. Il est déjà officiellement présent sur Nspire; il y a plus de 10 ans, un portage non officiel incomplet avait été réalisé sur TI-68k.
• Une adaptation du langage TI-Basic TI-68k (repris par la suite sur les Nspire). Cette solution pourrait être rendue envisageable par le fait que les capacités matérielles des CE sont plus proches de celles des TI-68k que de celles des TI-Z80 existant depuis plus de 20 ans. Cependant, elle demande énormément plus d’effort de développement que les deux autres, même pour TI qui dispose des codes source originels pour TI-68k et Nspire.

On a ensuite aussi rappelé que même si Lua est conforme, ça ferait un langage de plus à apprendre (contrairement à Python pour au moins une partie des profs). Par ailleurs, le gouvernement préférera les solutions libres/open-sources, donc une variante adaptée du TI-Basic ne serait pas forcément terrible de ce côté là (ou alors, ils l'ouvrent ).
On a aussi mentionné le fait qu'il faudra un éditeur sur calculatrice.

[critor]

Le Lua de la TI-Nspire a aussi l'inconvénient, comme on l'a il me semble précisé dans le document, d'avoir été un total échec dans le milieu francophone. Possiblement en grande partie à cause de l'obstination à ne pas fournir d'éditeur oncalc.

Il n'y a pas de raison qu'il se mette soudainement à avoir du succès si porté pour la TI-83PCE.

Les enseignants qui déjà vont être obligés de se taper l'apprentissage du Python, ne s'amuseront certainement pas simultanément à apprendre un autre nouveau langage juste pour la TI-83PCE.

[parisse]

C'est certainement plus facile de porter Lua que Python (meme en version allegee), puisque Lua est un langage prevu pour tourner sur des plateformes legeres. Je ne sais pas ce qu'il en est de porter le langage de la 92/nspire vers la 83, par contre je pense qu'ajouter des fonctions avec arguments et variables locales au langage de la 83 ne doit pas etre si difficile que ca : d'ailleurs il n'est pas impossible que le langage ait ete bride pour le marche US, avec la possibilite de le debrider assez facilement.
Concernant Python, on va voir comment la volonte d'en haut se heurtera aux realites du terrain...

[Adriweb]

En fait, Lua (et minilua, de LuaJIT), ont réussi à être compilés, déjà, avec la toolchain communautaire pour CE, voire linké pour une certaine version - sauf que le résultat était trop gros (110 KB je crois) pour tenir dans un seul programme (c'était il y a assez longtemps - on pourrait se débrouiller mieux aujourd'hui en bidouillant des choses pour splitter en appvar, voire faker une app). Cela dit, la stack et la heap vont probablement poser problème. Probablement que seul TI pourrait faire ce qu'il faut pour faire marcher ça correctement...

[Hamza.S]

le Basic 68k est, pour ma part, plus adapté proche du TI Basic (e)z80 niveau commande. On n'a pas à se casser la tête

[critor]

Je ne suis pas de cet avis.

J'ai peut-être perdu le fil.
Si c'est par rapport à l'intégration du Python sur calculatrice, j'admets volontiers que le langage unique est une mauvaise chose.

Quand je jongle (rapidement) en classe entre les langages TI-Basic, Casio Basic (et plus discrètement Nspire Basic), tous les élèves en profitent même ceux non concernés.
C'est sans doute pas grand chose, mais mine de rien c'est commencer à habituer à accepter de changer de langage, et à voir que ce n'est pas toujours une simple traduction, qu'il faut parfois penser différemment.

Quand dans quelques années des lycéens qui n'auront jamais fait que du Python (et du Scratch) si on suit l'ensemble des textes officiels, langage de plus avec une syntaxe assez spécifique, seront confrontés brutalement à la réalité des langages utilisés dans certaines filières de l'enseignement supérieur et/ou dans le monde professionnel, je crains qu'il puisse y avoir pas mal d'abandons...

Mais même si les textes officiels sont mauvais, je n'ai pas d'autre choix que de tenter de faire du mieux possible avec.
Il n'est pas dans mon style d'organiser un naufrage pour faire changer les textes.

Et dans ce contexte, je pense que l'intégration du Python sur les machines qui ne disposent pas encore d'un langage fonctionnel, est ce qu'il faut pour l'enseignement en classe et pour les candidats au BAC à compter de 2020.

C'est certainement plus facile de porter Lua que Python (meme en version allegee), puisque Lua est un langage prevu pour tourner sur des plateformes legeres. Je ne sais pas ce qu'il en est de porter le langage de la 92/nspire vers la 83, par contre je pense qu'ajouter des fonctions avec arguments et variables locales au langage de la 83 ne doit pas etre si difficile que ca

C'est quasiment tout le fonctionnement du langage qui serait à revoir.
Les programmes ne sont pas des fonctions, les variables sont toutes globales, et en prime elles ont un type préassocié à leur nom - il n'est pas possible de le redéfinir. Bref, quasiment tout est l'exact opposé de ce que demandent les textes.

Je pense personnellement qu'il est plus sage de repartir sur quelque chose de neuf/propre, comme une application dédiée portant le Python ou le Basic 68k/Nspire, voir même le Lua même si je prédis un échec, plutôt que de se lancer dans ce qui promet d'être un bricolage immonde, risquant même d'introduire des bugs dans le fonctionnement historique du TI-Basic qui vont embêter plein de pays pour les seules fantaisies de la France.

Mais après chez TI ils feront ce qu'ils voudront, et possiblement rien...