Cahier algorithmique 2nde Bordas 2018: retour calculatrices

[blouson]

Pourquoi ces petits programmes avec fonctions rament autant ? Par exemple celui pour la suite de Fibonacci pratiquement inutilisable à partir du 100 ème terme alors qu'un programme classique tourne très bien même si on met 10 000 ?

[critor]

Complexité exponentielle ?

[majestyofgaia]

Je relance un peu le topic mais pour parler du cahier de Belin, car il y a des choses qui m'interpellent.

Déjà première chose : je confirme (je ne sais plus qui l'avait signalé) qu'ils ont oublié à plusieurs reprises les : après des if en Python. C'est fâcheux !

Sinon :

1 - Pourquoi écrire x*x ou x**2 dans une chaîne de caractères ? Ca ne risque pas de créer des confusions chez les élèves ?



2 - Dans l'image ci-dessous, ils ont mis des print un peu partout. Moi, j'aurais tendance à les mettre plutôt à la fin, et même si possible à en utiliser qu'un avec une fstring ou au pire, en écrivant successivement des chaînes et des variables séparées par des virgules dans un seul print (ce qu'ils font parfois d'ailleurs, mais pas tout le temps...). Que faites-vous en général ?



Cette question est presque de la pure curiosité, car après discussions avec d'autres membres du forum, il semble qu'il faille tout écrire avec des fonctions (du moins dans la mesure du raisonnable, sans que ça devienne un casse-tête pour passer les fonctions en paramètre par exemple) mais pour les fois où je prendrais parti de garder des affichages, qu'est-ce qui vous semble le plus naturel ?

3 - Pour la dichotomie, ils ont fait comme moi. Seule la fonction est définie en fonction. Cela montre bien que les ipr vont avoir besoin d'éclaircir les choses.



4 - Ils parlent de Xcas dans un exercice. Alors pourquoi ne pas avoir parlé du langage Xcas ?



J'avais trouvé que le fil Twitter était parfois sévère envers le cahier, mais il fat reconnaître qu'il n'est pas exempt de tout reproche.

[majestyofgaia]

Hyperbole de Nathan sort aussi sa version d'un cahier d'algorithmique : langages calculatrices et Python

https://enseignants.nathan.fr/catalogue/cahier-d-algorithmique-et-de-programmation-hyperbole-2de-cahier-de-l-eleve-9782091726373.html?utm_source=2018%20NATH%20SCOL%20LYCEE&utm_medium=email&utm_campaign=NATH_201804_Nouveaut%C3%A9s-Papier

[Thom986]

Je relance un peu le topic mais pour parler du cahier de Belin, car il y a des choses qui m'interpellent.
[...]

C'est surtout que c'est assez nul comme programme... Genre les deux premiers sont quand même assez dénués d'intérêt.

Le pire étant le deuxième où plein de trucs inutiles jalonnent le programme...
* 4 appels à la fonction resist... qui aurait pu être remplacer par un R = resist(L,D) puis ensuite on demandait R...
* Des inputs dans une boucle for de 10... c'est pour moi assez étonnant...

[Bisam]

Il y a aussi la magnifique ligne 12 : resist(L,D)... qui ne sert strictement à RIEN.
Et puis, pourquoi cette incohérence de notation : de temps en temps, c'est print(...) (lignes 13 et 14) et de temps c'est print (...) (lignes 8,9,18,19,20,21,22) avec une espace entre le nom de la fonction et les parenthèses ?

Par ailleurs, pour la lisibilité, il serait préférable d'utiliser les recommandations d'écriture du PEP8, qui sont également résumées ICI.

[critor]

Je viens enfin de m'inscrire chez Belin pour accéder au spécimen numérique :
https://fr.calameo.com/read/003221622b2 ... x0WLPl4h8S

Vous avez la liste des 6 auteurs en page 1, histoire d'avoir leur ressenti.

Personnellement, je trouve qu'il y a eu un véritable travail proche des besoins des élèves.
En témoigne la présence des versions TI/Casio des programmes, puisque les élèves passeront l'examen avec ces machines et devraient donc logiquement y être préparés/entraînés avec.
Je trouve donc la déferlante de critiques sur Twitter assez injuste.

Après oui, j'avoue que les auteurs ont une interprétation assez originale de l'orientation fonctions donnée dans la dernière version des programmes :


Mais notons que parmi ce qui est en dehors de la fonction on trouve notamment l'interface au sens entrées/sorties, ce qui n'est pas une aberration, et définit bien à mon sens un 'programme' complet et donc facilement utilisable/compréhensible.

[majestyofgaia]

Après oui, j'avoue que les auteurs ont une interprétation assez originale de l'orientation fonctions donnée dans la dernière version des programmes

Je ne sais pas si j'ai bien interprété ce propos, mais si c'est le cas : n'est-ce pas pour garder un certain parallèle (tant que c'est possible) entre les différents langages, y compris Ti basic et Casio basique ? Si dans les fonctions on ne met que des formules, on peut travailler dans les 3 langages en entrant la formule dans Y1=, quelque soit le modèle.

Mon hypothèse s'écroule avec les exemples qui prennent plusieurs paramètres, certes, mais dans un premier temps, pour des élèves qui démarrent en algorithmique, ça peut faciliter les liens non ?

[critor]

Oui, c'est ce que je me disais.
Ils ont forcément de bonnes raisons de s'être embêtés à faire comme ça, ce qui a mon sens a nécessité du travail en plus.

[parisse]

Alors ce n'est pas le nombre d'arguments qui est discriminant, mais le fait que la fonction soit une fonction exprimable par une expression algebrique? Ce qui effectivement est portable sur beaucoup plus de modeles de calculatrices. Dans ce cas les boucles et tests devraient tous etre en-dehors des fonctions, et il n'y a pas de variables locales.
Il me semble que le programme officiel est assez silencieux sur la distinction entre fonctions algebriques ou non, et encore plus sur la notion de variables locales (puisque suivant Python il suppose tout cela implicite), or tout ca n'a rien d'evident et necessite certainement des etapes pour etre compris.