(maths) Formation aux aménagements du programme de seconde : algo/programmation

BrindIf a écrit:

Prezbo a écrit:Sinon, je suis convoqué à une formation PAF (sur candidature individuelle) "Python et algorithmique en classe de seconde". Vous raconterai.

Ah oui, merci !
Pour l'instant au niveau de mon établissement, la conclusion est de réserver Python aux 1re/Tle et de continuer avec Algobox en 2de, tout en faisant peut-être un peu attention à la rédaction des algorithmes sur papier.

Pour le MOOC, tu verras bien. C'est justement celui-ci qui m'a fait penser que c'était un système d'enseignement intéressant, avec plusieurs niveaux clairement affichés, et la possibilité de s'exercer en direct. Les vidéos sont courtes, mais ce n'est clairement pas une façon agréable d'apprendre quelque chose

Mais ce n’est pas au programme des 1res et Tles actuelles ...
D’autre part, il ne faut plus parler d’affichage dans un algorithme, donc Algobox me semble complètement désuet.

Ça me fait quand même un peu rigoler cette interdiction d'affichage. Ne doit-on plus faire programmer ni faire d'entrées/sorties ?
Parce qu'un programme qui ne demande rien à l'utilisateur, et qui n'affiche rien, ça risque de ne pas être très fun à faire passer auprès des élèves.
Accessoirement, la très grande majorité des cours de programmation que j'ai pu voir commencent par le traditionnel print("hello world").

Ne plus parler d’affichage? Je n’ai pas tout suivi. Quelle est la source officielle?

VinZT a écrit:Ça me fait quand même un peu rigoler cette interdiction d'affichage. Ne doit-on plus faire programmer ni faire d'entrées/sorties ?
Parce qu'un programme qui ne demande rien à l'utilisateur, et qui n'affiche rien, ça risque de ne pas être très fun à faire passer auprès des élèves.
Accessoirement, la très grande majorité des cours de programmation que j'ai pu voir commencent par le traditionnel print("hello world").

Ce n'est pas tout à fait comme ça qu'on va le présenter en formation dans mon académie. Pour faire simple, des entrées/sorties dans un programme, oui, mais pas dans une fonction.

Le glissement opéré par les aménagements du programme de seconde ne consiste pas à dire qu'on n'utilise jamais print ni n'interdit de faire un print("Hello world"). Il s'agit de s'écarter de l'idée de l'ancien programme selon laquelle un programme est systématiquement de la forme saisir les données au clavier/traiter les données/afficher le résultat à l'écran, idée qui est obsolète depuis les années 1970 au moins.

Badiste75 a écrit:
Ne plus parler d’affichage? Je n’ai pas tout suivi. Quelle est la source officielle?

Les consignes pour les algorithmes du bac, valables pour cette session. Je résume :
- plus de "prend la valeur" mais des flèches
- plus d'entrées/sorties
- plus de déclaration des variables
- le triptyque déclaration-initialisation-traitement est devenu subitement tout pourri

Edit : j'ai paumé le mail que l'inspection m'avait envoyé, mais j'ai trouvé le lien suivant, qui y correspond mot pout mot.

Académie de Montpellier a écrit:
Dans un objectif de simplicité et de cohérence, il est proposé une évolution de l’écriture des algorithmes dans les sujets de baccalauréat obéissant aux principes suivants :

suppression de la déclaration des variables, les hypothèses faites sur les variables étant précisées par ailleurs ;
suppression des entrées-sorties ;
simplification de la syntaxe, avec le symbole ← pour l’affectation.

http://disciplines.ac-montpellier.fr/mathematiques/examens-et-evaluation/bac-2018
http://disciplines.ac-montpellier.fr/mathematiques/sites/mathematiques/files/evolution-ecriture-algorithmes-bac.pdf

Certes. En tout cas, je suis parfaitement d’accord avec e1654d, ce n’est pas tout à fait la même chose!

dami1kd a écrit:Ce n'est pas tout à fait comme ça qu'on va le présenter en formation dans mon académie. Pour faire simple, des entrées/sorties dans un programme, oui, mais pas dans une fonction.

Ce qui peut s'avérer utile pour afficher, par exemple, les 100 premières décimales de 5/7 avec afficherDecimales(5,7)...

Code:

def afficherDecimales(n,d):
    print(n//d, end='.')
    n = n % d
    for i in range(100):
        print(10*n//d, end='')
        n = (10*n) % d
    print()


Call_BB5A a écrit:

dami1kd a écrit:Ce n'est pas tout à fait comme ça qu'on va le présenter en formation dans mon académie. Pour faire simple, des entrées/sorties dans un programme, oui, mais pas dans une fonction.

Ce qui peut s'avérer utile pour afficher, par exemple, les 100 premières décimales de 5/7 avec afficherDecimales(5,7)...

Code:

def afficherDecimales(n,d):
    print(n//d, end='.')
    n = n % d
    for i in range(100):
        print(10*n//d, end='')
        n = (10*n) % d
    print()


Et ca permet d'ailleurs de montrer une des différences entre fonction informatique et fonction mathématiques.

Badiste75 a écrit:Certes. En tout cas, je suis parfaitement d’accord avec e1654d, ce n’est pas tout à fait la même chose!

Il n'y a plus de question sur les affichages dans les sujets du Bac.

On aurait pu garder une ligne comme "Renvoyer ..." mais ce n'est pas le choix qui a été fait. Suffit de regarder les exemples du document envoyé par les IPR.

D’accord mais c’est pas pour autant que quand on programme on n’affiche pas.

Qu'est-ce qui empêche de faire une ligne qui appelle la fonction et affiche ce qui est retourné?

Matheod a écrit:

Call_BB5A a écrit:

dami1kd a écrit:Ce n'est pas tout à fait comme ça qu'on va le présenter en formation dans mon académie. Pour faire simple, des entrées/sorties dans un programme, oui, mais pas dans une fonction.

Ce qui peut s'avérer utile pour afficher, par exemple, les 100 premières décimales de 5/7 avec afficherDecimales(5,7)...

Code:

def afficherDecimales(n,d):
    print(n//d, end='.')
    n = n % d
    for i in range(100):
        print(10*n//d, end='')
        n = (10*n) % d
    print()


Et ca permet d'ailleurs de montrer une des différences entre fonction informatique et fonction mathématiques.

Et pour quelqu'un qui, comme moi, est une quiche en informatique, en quoi cet exemple montre-t-il une des différences entre fonction informatique et fonction mathématique ?
D'ailleurs je m'aperçois que je ne connais même de définition rigoureuse de ce qu'est une fonction informatique...

Moonchild a écrit:Et pour quelqu'un qui, comme moi, est une quiche en informatique, en quoi cet exemple montre-t-il une des différences entre fonction informatique et fonction mathématique ?

Je pense que la raison invoquée c'est parce que cette fonction informatique ne retourne aucune valeur. Même si certains préféreront alors parler de procédure plutôt que de fonction...

Un exemple simple de fonction informatique, qui ne soit pas une fonction au sens mathématique, c'est input. L'appel input("?") ne retourne pas toujours la même chaîne, puisque l'utilisateur est libre de taper ce qu'il veut, on ne peut donc pas parler de l'image de "?" par la fonction input...

D'ailleurs je m'aperçois que je ne connais même de définition rigoureuse de ce qu'est une fonction informatique...  

Pas grave, on a le même problème avec le mot "nombre" en mathématique.

Chez Laurent Cheno : https://tribu.phm.education.gouv.fr/portal/pagemarker/12/cms/default-domain/workspaces/activites-python-lycee?displayContext=breadcrumb&contextualization=page&scope=__nocache&pagePath=%252Ffoad%252F_dyn_cG9ydGFsU2l0ZVpHVm1ZWFZzZEMxa2IyMWhhVzRfZV9kZDI5eWEzTndZV05sY3dfZV9lX2RZV04wYVhacGRHVnpMWEI1ZEdodmJpMXNlV05sWlFfZV9l.Y21zOi9kZWZhdWx0LWRvbWFpbi93b3Jrc3BhY2VzL2FjdGl2aXRlcy1weXRob24tbHljZWU%253D.X19OX18%253D.X19OX18%253D.X19OX18%253D&pageParams=

Euh … sérieusement ? En seconde ?
Et même en TS avec la course perpétuelle …
J'ai l'impression que la seule compétence que l'on va tester chez les élèves est : « sait recopier sans erreur un programme écrit par quelqu'un d'autre ».
Enfin, on peut toujours se faire plaisir …

Call_BB5A a écrit:Un exemple simple de fonction informatique, qui ne soit pas une fonction au sens mathématique, c'est input. [color=#FF0000]

Je ne comprends pas: cette fonction (?) affecte à une variable A$ les données entrées par un utilisateur.
Pour deux utilisateurs différents qui appuient sur les mêmes touches, A$ prendra exactement la même valeur.

wanax a écrit:

Call_BB5A a écrit:Un exemple simple de fonction informatique, qui ne soit pas une fonction au sens mathématique, c'est input. [color=#FF0000]

Je ne comprends pas: cette fonction (?) affecte à une variable A$ les données entrées par un utilisateur.
Pour deux utilisateurs différents qui appuient sur les mêmes touches, A$ prendra exactement la même valeur.

Oui, sauf que ce que rentre l'utilisateur n'est pas l'argument transmis lors de l'appel de la fonction. Ce que rentre l'utilisateur est un effet de bord.

Pour être plus clair avec l'exemple suivant :

Code:

nom = input("Quel est ton nom ?")

On invoque la fonction input avec l'argument "Quel est ton nom ?", comme quand on invoque la fonction f avec l'argument 5 lorsqu'on écrit f(5).

Ainsi, si input était une fonction mathématique, la variable nom devrait recevoir toujours la même valeur : l'image de "Quel est ton nom ?" par la fonction input. Ce qui n'est pas le cas, puisque ceci dépend de l'utilisateur...

dami1kd a écrit:

VinZT a écrit:Ça me fait quand même un peu rigoler cette interdiction d'affichage. Ne doit-on plus faire programmer ni faire d'entrées/sorties ?
Parce qu'un programme qui ne demande rien à l'utilisateur, et qui n'affiche rien, ça risque de ne pas être très fun à faire passer auprès des élèves.
Accessoirement, la très grande majorité des cours de programmation que j'ai pu voir commencent par le traditionnel print("hello world").

Ce n'est pas tout à fait comme ça qu'on va le présenter en formation dans mon académie. Pour faire simple, des entrées/sorties dans un programme, oui, mais pas dans une fonction.

Ah oui....

Ce n'est pourtant pas compliqué.
Par exemple, imaginons un script permettant de calculer le PGCD de deux nombres.
Au lieu de créer une fonction pgcd() dont les premières lignes seraient a=input("premier nombre") et b=input("second nombre") et qui se terminerait par un print("le pgcd est " + str(d)), il est recommandé de créer une fonction pgcd(a,b) qui prendrait donc les deux nombres en argument et qui se terminerait par un return d.

Cela ne revient pas à faire un programme qui ne demande rien (l'utilisateur a bien rentré les arguments en appelant la fonction) et qui n'afficherait rien (la fonction renvoie bien le pgcd).

L'avantage est simple : une telle fonction serait réutilisable dans une autre fonction (par exemple, une fonction qui rend une fraction irréductible), ce qui ne serait pas le cas avec des input et des print (le renvoi du print est inexploitable).

Call_BB5A a écrit:

wanax a écrit:

Call_BB5A a écrit:Un exemple simple de fonction informatique, qui ne soit pas une fonction au sens mathématique, c'est input. [color=#FF0000]

Je ne comprends pas: cette fonction (?) affecte à une variable A$ les données entrées par un utilisateur.
Pour deux utilisateurs différents qui appuient sur les mêmes touches, A$ prendra exactement la même valeur.

Oui, sauf que ce que rentre l'utilisateur n'est pas l'argument transmis lors de l'appel de la fonction. Ce que rentre l'utilisateur est un effet de bord.

Pour être plus clair avec l'exemple suivant :

Code:

nom = input("Quel est ton nom ?")

On invoque la fonction input avec l'argument "Quel est ton nom ?", comme quand on invoque la fonction f avec l'argument 5 lorsqu'on écrit f(5).

Ainsi, si input était une fonction mathématique, la variable nom devrait recevoir toujours la même valeur : l'image de "Quel est ton nom ?" par la fonction input. Ce qui n'est pas le cas, puisque ceci dépend de l'utilisateur...

Pas d'accord du tout. Quel est ton nom ? n'est en rien un antécédent/argument d'input, c'est purement cosmétique.
On peut écrire :
print "Quel est ton nom ?"
input a$
Et c'est exactement la même chose.

L'"argument" au sens usuel du terme et que je veux bien recevoir, c'est que l'entrée dépend de l'utilisateur et pas du programme en cours d'exécution.
On peut considérer le cas où l'utilisateur ne parle pas français, ne veut pas donner son vrai nom, etc... et réponde: 42.
Ce qui rapprocherait alors la fonction input d'un jet de dé: quel confiance accorder à ce qu'a entré l'utilisateur ?
Mais en fait, la variabilité des images ne s'explique pas par un comportement variable de la fonction, mais par la variabilité des antécédents.
Ce n'est pas input qui décide ou calcule que je vais appuyer sur la touche W, son rôle se limite à transférer à une variable l'information lue sur le senseur touche.
( Et il y aussi la solution que tu mentionnes sur un autre fil et que j'aime bien :

Oui, ce sont des fonctions impures. On peut les ramener dans le cadre des fonctions pures en explicitant l'environnement d'exécution comme paramètre (environnement dans lequel on appelle la fonction) et comme partie du résultat (environnement résultat de l'exécution).

)

Quitte à divaguer: il y a une composée :  g la fonction (clavier -> variable nom), f la fonction effectuée par le cerveau humain ( question lue -> réponse choisie )
Si on décide que input, c'est g o f, tu as raison, si on décide que c'est g, c'est moi.
( Et je suis prêt à changer d'avis. )

Non, ce n'est pas la même chose d'écrire

Code:

print("toto")
a = input()

et d'écrire

Code:

a = input("toto")

. Dans ce dernier code, "toto" est bien le paramètre effectif de l'appel à la fonction input.

Quant à

Code:

print "Quel est ton nom ?"
input a$

, c'est manifestement un programme écrit dans un autre langage, donc la comparaison est difficile (est-ce que dans cet autre langage, input et print sont des fonctions ?).

Du basic ZX81
Je maintiens.

Si j'en crois http://otremolet.free.fr/otnet/otzx/zx81/basic-progr/appxc.html (qui semble être une reproduction du manuel de l'époque), en BASIC ZX81, INPUT n'est pas une fonction mais une instruction ; il n'a donc pas de résultat, ce qui rend la discussion sans objet.

Ah.

wanax a écrit:Quitte à divaguer: il y a une composée :  g la fonction (clavier -> variable nom), f la fonction effectuée par le cerveau humain ( question lue -> réponse choisie )
Si on décide que input, c'est g o f, tu as raison, si on décide que c'est g, c'est moi.
( Et je suis prêt à changer d'avis. )

L'humain ne rentre pas en ligne de compte si on considère qu'une entrée peut être aussi effectuée sur un fichier.

Pour que g soit une fonction au sens mathématique il faut que la valeur retournée par g soit l'image de l'argument explicite passé à g. Il ne peut y avoir de variable cachée ou de paramètre extérieur... de la même façon que cos(60°) est parfaitement défini comme étant l'image de 60°, et constitue un nombre qui ne peut varier (cos(60°) est invariablement égal à 0.5).

Voici un exemple peut-être plus convaincant en Python :

Code:

mot1 = input("mot suivant ?")
mot2 = input("mot suivant ?")

Il est clair que les variables mot1 et mot2 peuvent contenir des valeurs différentes, quand bien même on appelle dans les deux cas la fonction input avec le même argument (la chaîne "mot suivant ?"). La fonction informatique input n'est pas une fonction au sens mathématique.


Puisque le basic ZX81 est proche du QBasic/QuickBasic, voici un programme dans lequel la fonction Entree$, qui est appelée avec le même argument "Mot suivant ?", ne retourne pas toujours la même valeur. Ceci permet d'affirmer que Entree$ n'est pas une fonction mathématique.

Code:

DECLARE FUNCTION Entree$ (Message$)
Mot1$ = Entree$("Mot suivant ?")
Mot2$ = Entree$("Mot suivant ?")
PRINT "Mot1="; Mot1$
PRINT "Mot2="; Mot2$
END

FUNCTION Entree$ (Message$)
    PRINT Message$;
    INPUT Reponse$
    Entree$ = Reponse$
END FUNCTION