Programme 2nde 2017, fin de la programmation calculatrices

My calculator programs · by **Adriweb** » 15 Apr 2018, 12:10

Oui bien sûr, je parlais ici de la faisabilité technique sans avoir recours à du natif / non-TI.

Malheureusement je doute que, d'ici Juin 2019, TI trouve un moyen pour rendre certains scripts Lua autorisés en PTT...

Ils n'ont qu'a porter MicroPython, c'est pas très compliqué pour être au niveau de la concurrence (pas ou presque de libs, pas de bindings...)

→ **MyCalcs** profile · by **critor** » 15 Apr 2018, 12:43

Et pour la TI-83, tu paries aussi sur un portage d'un MicroPython possiblement allégé sur TI-83 Premium CE, ou bien sur un nouveau modèle peut-être basé sur la technologie Nspire comme la TI-83 Francium X ?

My calculator programs · by **Adriweb** » 15 Apr 2018, 14:58

Aucune idée, faudrait déjà savoir s'ils décident tout court d'inclure du python, pour le moment toujours aucune annonce (même discrète lors de formations T3), à ce que je sache.
C'est sûr qu'une "CE" tournant à base de hardware Nspire(-like), ça simplifierait grandement la tâche... Mais ça serait probablement plus cher aussi pour l'utilisateur final, alors bon...

→ **MyCalcs** profile · by **parisse** » 15 Apr 2018, 16:21

Adriweb wrote:Au passage, sans revenir sur le débat de quel langage serait mieux par rapport à ce qu'il engendre ou non côté sécurité pour des débutants,

Je pense qu'il n'y a pas lieu d'avoir un debat sur la securite d'un langage, ca n'a rien a voir avec les objectifs de l'enseignement de l'algorithmique au lycee.

il ne serait pas impossible de faire une sorte de couche de traduction python=>lua sur Nspire (en lua), ""comme"" le fait Xcas avec la gestion de la syntaxe. Ca demanderait un peu d'huile de coude pour que ca fonctionne suffisamment correctement, mais...
Alors certes, il n'y aurait pas non plus les vraies libs du genre numpy, mais comme on a accès au moteur de calcul de la machine, on pourrait imaginer de jolis bindings pour reconstruire beaucoup de fonctionnalités.

Oui, pour l'enseignement de l'algorithmique utile en maths, tous ces langages sont essentiellement equivalents, passer de python vers lua ne doit pas etre plus difficile que de python vers xcas. Ajouter de la compatibilite pour les librairies, c'est un travail plus ou moins difficile et pertinent selon la librairie. Assez facile par exemple pour math, cmath et random. Pour numpy, je vais me contenter de quelques fonctions de base pour permettre la compatibilite avec des scripts simples mais franchement je ne suis pas emballe, pour matplotlib, je pense que ca n'a pas d'interet, car les commandes CAS pour tracer des graphes au niveau lycee sont beaucoup plus simples grace aux expressions symboliques (d'ailleurs sagemath ne semble pas les utiliser).

→ **MyCalcs** profile · by **Lionel Debroux** » 15 Apr 2018, 17:46

Quand les bizarreries d'un langage peuvent interférer avec l'enseignement de l'algorithmique qu'on veut réaliser avec ledit langage, c'est un problème

En JS, j'avais vu que même === ne suffit pas pour avoir une égalité saine.

→ **MyCalcs** profile · by **parisse** » 15 Apr 2018, 18:45

Lionel Debroux wrote:Quand les bizarreries d'un langage peuvent interférer avec l'enseignement de l'algorithmique qu'on veut réaliser avec ledit langage, c'est un problème

Que dire alors de la division d'entiers en Python qui renvoie un flottant ? Javascript n'a pas de type entier, bien sur c'est moins complet que Python, mais c'est quand meme plus simple a expliquer a des debutants pour les operations arithmetiques de base.

En JS, j'avais vu que même === ne suffit pas pour avoir une égalité saine.

Je ne comprends pas, pour ma part j'ai toujours utilise == sans rencontrer de problemes. Si on met de cote les questions de tests d'egalite entre flottants qui sont universels, ou rencontre-t-on des problemes au niveau lycee?

→ **MyCalcs** profile · by **Lionel Debroux** » 19 Apr 2018, 14:31

Le === de JS a été fait parce que == rend une valeur de vérité pour des comparaisons entre des objets qui n'ont pas le même type, ce qui est embêtant dans les cas limites. Mais je crois avoir vu quelque part que même === n'est pas parfait.

→ **MyCalcs** profile · by **parisse** » 19 Apr 2018, 16:07

Lionel Debroux wrote:Le === de JS a été fait parce que == rend une valeur de vérité pour des comparaisons entre des objets qui n'ont pas le même type, ce qui est embêtant dans les cas limites. Mais je crois avoir vu quelque part que même === n'est pas parfait.

J'aimerais bien voir des exemples concrets ou cela pose probleme, et plus particulierement au niveau lycee.
D'ailleurs l'egalite peut renvoyer vrai pour des objets de type different dans d'autres langages, par exemple 3==3.0 renvoie True en Python ou en C.

My calculator programs · by **Adriweb** » 19 Apr 2018, 16:16

Le JS en général provoque de vives réactions, mais la plupart du temps c'est du au weak typing.

Exemples de choses qui pourront paraitre surprenantes à beaucoup : https://www.destroyallsoftware.com/talks/wat

Dans le même style, à cause de type coercion :

Sinon, il y a ce bon vieux diagramme... :

Tout ceci c'est du à l'usage de ==. Il faut, peu importe la situation, utiliser === partout. Et utiliser des outils (linters/IDE...) qui "empêchent" de faire autrement, si possible.

→ **MyCalcs** profile · by **Lionel Debroux** » 19 Apr 2018, 16:27

Merci. Je connaissais le deuxième diagramme mais j'avais la flemme de le chercher; et le premier montre que c'est pire que ce que je savais...

Les jeunes lycéens peuvent trop facilement prendre de mauvaises habitudes de codage avec JS, ou perdre du temps eux-mêmes sur des conneries quand ils font du code, ou en faire perdre à l'enseignant et à la classe.