π
<-
Chat plein-écran
[^]

Le Python Graph 90+E sera une appli intégrée dispo en examen

Re: Le Python Graph 90+E sera une appli intégrée dispo en ex

Unread postby majestyofgaia » 19 Apr 2018, 11:24

parisse wrote:La possibilite de choisir, c'est aussi la garantie qu'en cas de changement d'etablissement l'enseignant peut continuer a utiliser le langage qu'il maitrise. Les ressources elles existent deja dans de nombreux langages. Et pour les eleves, je pense que la diversite est une richesse.


Si un langage unique est imposé, le changement d'établissement ne posera pas de problème ! Mais je comprends vos arguments, d'autant plus que je suis assez d'accord avec la deuxième partie du propos. Mais avoir un langage prédominant dans un premier temps (par exemple en 2nde et 1ère), puis une fois bien ancrées les bases, s'intéresser à d'autres langages (en terminale) pour voir les liens et les différences ça peut être pas mal non ?

A l'origine je ne suis pas fan de l'idée d'imposer un langage pour tous, mais il y a aussi des avantages selon moi, notamment dans l'entraide. Si tout le monde utilise le même langage, et qu'un collègue galère, on peut l'épauler plus facilement. Au niveau des ressources internet, on trouvera plus facilement ce que l'on cherche sans avoir à maîtriser plein de langages pour réécrire dans le langage voulu. Bref, je trouve que tout n'est pas noir dans cette approche.

Quant au choix du Python, j'imagine que c'est un retour d'expérience non ? En tout cas mes secondes adhèrent bien mieux à l'algorithme depuis que l'on travaille sur Python. Le visuel dû à l'indentation y est pour beaucoup (par rapport aux Casio basic ou Ti basic, pour avoir testé les deux) ! Quant aux boutons sur Algobox, ils trouvaient ça laborieux, et les lignes superflues (notamment le Si, c'est lourd...) ça alourdissait inutilement le visuel. Je dis ça alors que j'étais un partisan d'Algobox il y a 9 ans, quand les programmes de 2009 sont sortis.

Enfin, la création de fonctions sur Python, c'est le pied ! Sur Casio / Ti, il fallait entrer une formule dans Y1, puis aller chercher Y1 dans le programme. Ce n'était pas hyper naturel pour eux. Là ils font def f(x): return ..... et ils utilisent f(x) dans le programme. C'est intuitif ! Du coup, je suis assez partisan du Python.
User avatar
majestyofgaiaVIP+
Niveau 7: EP (Espèce Protégée: geek)
Niveau 7: EP (Espèce Protégée: geek)
Level up: 75%
 
Posts: 104
Joined: 17 Nov 2013, 16:20
Gender: Not specified
Calculator(s):

Re: Le Python Graph 90+E sera une appli intégrée dispo en ex

Unread postby parisse » 19 Apr 2018, 14:55

D'abord, merci pour ce retour d'experience, c'est le premier retour d'un utilisateur apparamment "lambda" en faveur de Python. La comparaison avec les langages des calculatrices non formelles est toutefois un peu biaisee. Avez-vous deja essaye de programmer avec Xcas ?
Je precise que je ne defends absolument pas Algobox, je dis simplement que le collegue qui est habitue a Algobox a beaucoup moins de chance de se retrouver bloque par un eleve sur une erreur due a une mauvaise maitrise du logiciel pendant une seance, et a ce moment-la difficile de demander de l'aide a un collegue. De mon cote, j'ai observe des collegues, utilisant Python avec leurs eleves, bloquer sur leur propre code Python (en preparant des TP ecrits a la fois en langage Xcas et Python), je ne crois pas que ca aide pour debloquer les eleves (sauf si on a fait la meme erreur bien sur).

Concernant les ressources, je pense qu'une saine emulation entre langages devrait en augmenter la qualite (on voit de tout, y compris dans les codes Python fournis en exemple dans les formations academiques).

Je termine par des points qui font que je pense que Python n'est pas un langage ideal en tout cas pour faire des maths:
  • utilisation de ** pour ^, division de 2 entiers / renvoyant un flottant
  • on a un type entier, mais l'utilisation des rationnels n'est pas tres naturelle.
  • pas de type vecteur ou matrice (ainsi + sur 2 listes concatene 2 listes)
  • pas d'expression symboliques (ni d'equations). Consequence: pour faire une dichotomie generale, il faut passer une fonction en argument a une autre fonction, ce qui exige un certain niveau d'abstraction (certains etudiants ont deja du mal avec des arguments normaux pour une fonction). Faire une representation graphique necessite aussi plus de travail qu'avec un CAS ou une calculatrice formelle et risque de passer pour une suite d'instructions difficiles a comprendre sans meme parler de la creer.
  • pour les complexes, utilisation de j et de la multiplication implicite alors que partout ailleurs on utilise la multiplication explicite

Pour la programmation en elle-meme:
  • l'affectation par = peut engendrer des confusions avec les equations en mathematiques
  • je n'aime pas devoir utiliser des objets compliques pour faire des choses simples, or c'est precisement ce qui se passe pour la boucle for en Python.
  • les listes sont passees par reference, alors que les autres types sont passes par valeur, ca peut etonner
  • l'indentation pour structurer les fins de blocs a de mon point de vue un gros inconvenient: si on copie-colle un bloc dans une autre structure on ne peut pas le reindenter automatiquement contrairement aux autres langages. Ca peut etre difficile de savoir ou est la fin de bloc s'il y a changement de page dans un code imprime. On le voit aussi dans les echanges sur forum (probablement aussi certains lecteurs de mail) ou les debutants inserent leur code sans precaution et ou l'indentation est perdue. Et c'est sans doute plus difficile pour des deficients visuels.
  • les variables locales sont implicites dans les fonctions Python. Cela peut etre source d'erreur en cas de faute de frappe.

Pour toutes ces raisons, je considere Python comme un choix possible parmi d'autres langages, mais il ne faut absolument pas l'imposer. S'il est vraiment meilleur que les autres, il s'imposera de lui-meme, encore faut-il que la concurrence ne soit pas faussee!
User avatar
parisseVIP++
Niveau 11: LV (Légende Vivante)
Niveau 11: LV (Légende Vivante)
Level up: 69.9%
 
Posts: 1704
Joined: 13 Dec 2013, 16:35
Gender: Not specified

Re: Le Python Graph 90+E sera une appli intégrée dispo en ex

Unread postby majestyofgaia » 19 Apr 2018, 17:39

Analyse très technique (trop pour moi) mais j'aimerais répondre sur certains points et avoir quelques précisions sur d'autres. En tout cas, visiblement il me reste encore beaucoup à apprendre !

Avez-vous deja essaye de programmer avec Xcas ?


Pour être honnête, très peu. J'avais regardé Xcas et Scilab au tout début de l'arrivée de l'algorithmique mais mon choix s'était porté sur Algobox car j'avais peur que ces langages soient rebutants à cause de la syntaxe. Ils m'avaient intéressé, mais vu que dans la pratique je ne l'aurais pas utilisé avec mes élèves et que j'étais en début de carrière d'enseignant (c'était ma 2ème année à l'époque), mes efforts se sont portés sur d'autres choses. Et puis récemment, j'ai pu voir l'engouement pour Python, donc il y a presque deux ans maintenant, j'ai acheté quelques bouquins et je m'y suis mis. Mais ce n'est que de l'autoformation, malheureusement, je n'ai trouvé aucune formation proposée par l'EN pour avoir de bonnes bases théoriques.

Je rejetterai un oeil sur Xcas quand même, par curiosité.

De mon cote, j'ai observe des collegues, utilisant Python avec leurs eleves, bloquer sur leur propre code Python (en preparant des TP ecrits a la fois en langage Xcas et Python), je ne crois pas que ca aide pour debloquer les eleves (sauf si on a fait la meme erreur bien sur).


En fait, je n'ai pas trop eu de problèmes à ce niveau là pour le moment, mais peut-être parce qu'en seconde les programmes restent simples. Et les erreurs des élèves sont souvent les mêmes : oubli des :, problème d'indentation, on écrit une fonction mais on ne l'appelle jamais... mais j'avoue que je crains voir arriver bientôt le jour où je ne saurai pas résoudre le problème ! Mais pour l'instant, le shell m'explique bien le problème donc je m'en sors. Croisons les doigts pour que ça continue !

utilisation de ** pour ^, division de 2 entiers / renvoyant un flottant

Dès le début j'explique que / renvoie un float et // renvoie un entier, et en général ils comprennent vite. Donc ça va franchement. Je suis presque plus gêné par la fonction input qui renvoie une chaîne systématiquement. Au début, les élèves ne perçoivent pas bien la différence entre 5 et "5". C'est seulement quand j'écris 3+5 et "3"+"5" qu'ils visualisent un peu. Et ça, je reconnais que c'est gênant.

on a un type entier, mais l'utilisation des rationnels n'est pas tres naturelle.

C'est vrai. En 1ère S cette année, j'ai du coup utilisé le module fractions pour l'algorithme qui détermine la mesure principale d'un angle. Ca m'a sauvé la vie.

pas de type vecteur ou matrice (ainsi + sur 2 listes concatene 2 listes)

Je n'ai pas tout compris... là, on atteint mes limites ! ^^

pas d'expression symboliques (ni d'equations).

Avec le module sympy on peut non ? J'ai réussi par exemple à récupérer d'un champ de saisie (du module tkinter) une expression de f(x) et la faire évaluer avec la fonction eval pour une valeur donnée.

Consequence: pour faire une dichotomie generale, il faut passer une fonction en argument a une autre fonction, ce qui exige un certain niveau d'abstraction (certains etudiants ont deja du mal avec des arguments normaux pour une fonction).

Je ne sais pas ce qu'est la dichotomie "générale". Moi au lycée, je traite la dichotomie de façon très simple. Je définis une fonction, et j'utilise l'algorithme classique avec le test f(a) x f(m) >0. Il suffit de vérifier les conditions du TVI. Peut-être ne vais-je pas assez loin.

Faire une representation graphique necessite aussi plus de travail qu'avec un CAS ou une calculatrice formelle et risque de passer pour une suite d'instructions difficiles a comprendre sans meme parler de la creer.

Là dessus, je suis complètement d'accord. C'est pour moi le point faible. C'est la raison pour laquelle j'espère vraiment que Casio réussisse à créer une interactivité entre les menus. Ainsi, la création de points depuis Python pour les afficher dans le menu graph deviendra un jeu d'enfants.

Pour les complexes, utilisation de j et de la multiplication implicite alors que partout ailleurs on utilise la multiplication explicite

Pour j je comprends la remarque, mais au final ça ne concerne que les terminales, donc ils ne sont pas freinés par si peu. Au pire, dans le module sympy, il me semble que le i complexe est un I (i majuscule). Quant à la multiplication implicite, j'avoue que je ne l'avais pas remarqué ! C'est vrai que ça peut dérouter.


Pour la programmation en elle-meme : l'affectation par = peut engendrer des confusions avec les equations en mathematiques

J'avais déjà entendu cet argument, mais j'avoue ne l'avoir jamais constaté. Le fait est que dans l'algorithmique on utilise une flèche et qu'ils commencent pas ça. Donc le concept de l'affectation est normalement ancré avant l'introduction du symbole = non ? Et puis quand je tape, je ne dis jamais égal, je dis toujours "prend la valeur". C'est un réflexe quasi-pavlovien.

je n'aime pas devoir utiliser des objets compliques pour faire des choses simples, or c'est precisement ce qui se passe pour la boucle for en Python.

Je ne comprends pas trop. C'est de l'informatique pur j'imagine non ?

les listes sont passees par reference, alors que les autres types sont passes par valeur, ca peut etonner

Ca je crois peut-être comprendre : c'est ce qui explique que si je fais ceci :
a = [1, 3, 5]
b = a
a.remove(1)
print(b)

Ca m'affichera [3, 5] car a et b pointent vers le même objet ? Ou alors ça n'a rien à voir et je n'ai rien compris... :?

Mais est-ce que ça ne devient pas trop "technique" pour des élèves ? Je veux dire, je sais bien qu'on ne leur parlera jamais de ça, mais seront-ils réellement confrontés au problème ?

l'indentation pour structurer les fins de blocs a de mon point de vue un gros inconvenient: si on copie-colle un bloc dans une autre structure on ne peut pas le reindenter automatiquement contrairement aux autres langages. Ca peut etre difficile de savoir ou est la fin de bloc s'il y a changement de page dans un code imprime. On le voit aussi dans les echanges sur forum (probablement aussi certains lecteurs de mail) ou les debutants inserent leur code sans precaution et ou l'indentation est perdue. Et c'est sans doute plus difficile pour des deficients visuels.


Je comprends, mais moi qui suis visuel par exemple, cette organisation m'aide vraiment du point de vue algorithmique. Par exemple, les accolades en java, que certains mettent en début de ligne seule, en début de ligne suivie d'une première instruction, à la fin d'une condition ou de la définition d'une fonction... je ne m'y retrouve pas. Alors qu'en Python, c'est clair, c'est net, et je trouve ça bien organisé. Mais j'avoue que c'est très personnel.

les variables locales sont implicites dans les fonctions Python. Cela peut etre source d'erreur en cas de faute de frappe.

C'est vrai. Pour l'instant je n'ai pas encore été confronté au problème, mais il faut en tenir compte, je le reconnais.

Pour toutes ces raisons, je considere Python comme un choix possible parmi d'autres langages, mais il ne faut absolument pas l'imposer. S'il est vraiment meilleur que les autres, il s'imposera de lui-meme, encore faut-il que la concurrence ne soit pas faussee!


La concurrence est faussée par l'ipr, il est vrai. Peut-être auraient-ils dû communiquer sur les raisons du choix. Ils auraient peut-être convaincu. Après, je reste sur ma position : j'y vois des avantages et des inconvénients à vouloir imposer un langage. Donc on verra ce qu'il en sera par la suite. Mais je ferai quand même l'effort de mon côté d'aller regarder du côté de Xcas.
User avatar
majestyofgaiaVIP+
Niveau 7: EP (Espèce Protégée: geek)
Niveau 7: EP (Espèce Protégée: geek)
Level up: 75%
 
Posts: 104
Joined: 17 Nov 2013, 16:20
Gender: Not specified
Calculator(s):

Re: Le Python Graph 90+E sera une appli intégrée dispo en ex

Unread postby parisse » 19 Apr 2018, 21:25

majestyofgaia wrote: Et puis récemment, j'ai pu voir l'engouement pour Python, donc il y a presque deux ans maintenant, j'ai acheté quelques bouquins et je m'y suis mis. Mais ce n'est que de l'autoformation, malheureusement, je n'ai trouvé aucune formation proposée par l'EN pour avoir de bonnes bases théoriques.

Donc finalement vous n'etes pas si "lambda" que ca, je ne pense pas que la majorite des profs s'achete des bouquins pour enseigner l'algorithmique.

En 1ère S cette année, j'ai du coup utilisé le module fractions pour l'algorithme qui détermine la mesure principale d'un angle. Ca m'a sauvé la vie.

C'est precisement sur ce genre de choses qu'on voit que Python n'est pas un langage prevu pour faire des maths, en Xcas (ou sur n'importe quelle calculatrice formelle), / a le meme sens qu'en maths, si vous ecrivez 1/2 cela renvoie un rationnel.

pas de type vecteur ou matrice (ainsi + sur 2 listes concatene 2 listes)

Je n'ai pas tout compris... là, on atteint mes limites ! ^^

Meme chose ici. En Python vous ne pouvez pas additionner 2 vecteurs [1,2]+[3,4] renvoie [1,2,3,4] au lieu de [4,6]. Il faut a nouveau faire appel a une librairie, avec des types pas toujours evidents, et des notations peu pratiques, par exemple dot() pour faire un produit.

pas d'expression symboliques (ni d'equations).

Avec le module sympy on peut non ? J'ai réussi par exemple à récupérer d'un champ de saisie (du module tkinter) une expression de f(x) et la faire évaluer avec la fonction eval pour une valeur donnée.

Pour faire du calcul symbolique depuis Python, je vous conseille giacpy qui est bien plus puissant que sympy (giacpy est l'interface Python de Giac, le moteur de calcul formel de Xcas). Mais quel que soit le module que vous ajoutez, vous n'aurez jamais une utilisation aussi simple que dans un CAS ou une calculatrice formelle, par exemple il faut declarer des variables symboliques, puisqu'on ne peut pas evaluer une variable libre en Python.

Consequence: pour faire une dichotomie generale, il faut passer une fonction en argument a une autre fonction, ce qui exige un certain niveau d'abstraction (certains etudiants ont deja du mal avec des arguments normaux pour une fonction).

Je ne sais pas ce qu'est la dichotomie "générale". Moi au lycée, je traite la dichotomie de façon très simple. Je définis une fonction, et j'utilise l'algorithme classique avec le test f(a) x f(m) >0. Il suffit de vérifier les conditions du TVI. Peut-être ne vais-je pas assez loin.

Par generale, j'entends une fonction dichotomie prenant en argument la fonction f dont on cherche une racine. Pour une fraction des eleves, le concept de fonction n'est deja pas naturel, passer une fonction en argument a une autre fonction devient tres abstrait (par exemple dicho(lambda x:cos(x),0,1,1e-10). Passer une expression en argument est plus facile a comprendre: dicho(cos(x)-x,0,1,1e-10)).

Faire une representation graphique necessite aussi plus de travail qu'avec un CAS ou une calculatrice formelle et risque de passer pour une suite d'instructions difficiles a comprendre sans meme parler de la creer.

Là dessus, je suis complètement d'accord. C'est pour moi le point faible. C'est la raison pour laquelle j'espère vraiment que Casio réussisse à créer une interactivité entre les menus. Ainsi, la création de points depuis Python pour les afficher dans le menu graph deviendra un jeu d'enfants.

Je ne pense pas que Casio fera grand chose d'autre que Numworks, i.e. une instruction pour afficher un pixel. On est tres loin de la possibilite de tracer un graphe avec une commande plot().


Pour la programmation en elle-meme : l'affectation par = peut engendrer des confusions avec les equations en mathematiques

J'avais déjà entendu cet argument, mais j'avoue ne l'avoir jamais constaté.

Ca doit dependre des profs, c'est une des premieres remarques qu'on m'a faite sur l'interet d'utiliser Xcas (en syntaxe Xcas).

je n'aime pas devoir utiliser des objets compliques pour faire des choses simples, or c'est precisement ce qui se passe pour la boucle for en Python.

Je ne comprends pas trop. C'est de l'informatique pur j'imagine non ?

Non, c'est plutot lie a la complexite en memoire. En Python 2, quand on ecrit for j in range(10000) l'interpreteur genere une liste de 10000 entiers de 0 a 9999, ce qui est inutile pour faire une boucle for. En Python 3, pour eviter cela, range renvoie un objet assez abstrait. Je ne comprends pas pourquoi ils veulent absolument faire une boucle definie sur une liste, alors que naturellement on itere sur des entiers et presque tous les langages le font.

les listes sont passees par reference, alors que les autres types sont passes par valeur, ca peut etonner

Ca je crois peut-être comprendre : c'est ce qui explique que si je fais ceci :
a = [1, 3, 5]
b = a
a.remove(1)
print(b)

Ca m'affichera [3, 5] car a et b pointent vers le même objet ? Ou alors ça n'a rien à voir et je n'ai rien compris... :?

C'est precisement ca.

Mais est-ce que ça ne devient pas trop "technique" pour des élèves ? Je veux dire, je sais bien qu'on ne leur parlera jamais de ça, mais seront-ils réellement confrontés au problème ?

Je pense que oui, si ils ecrivent des algorithmes sur les vecteurs ou sur les matrices.

Je comprends, mais moi qui suis visuel par exemple, cette organisation m'aide vraiment du point de vue algorithmique. Par exemple, les accolades en java, que certains mettent en début de ligne seule, en début de ligne suivie d'une première instruction, à la fin d'une condition ou de la définition d'une fonction... je ne m'y retrouve pas. Alors qu'en Python, c'est clair, c'est net, et je trouve ça bien organisé. Mais j'avoue que c'est très personnel.

Dans les autres langages, l'indentation n'est pas obligatoire, mais presque tout le mode indente ce qui aboutit au meme resultat qu'en Python visuellement, l'avantage c'est que l'editeur de texte le fait automatiquement. On repere de cette facon les oublis d'instructions de fin de structure ou des parentheses/crochets/etc. mal fermes. Le seul avantage que je vois a Python la-dessus, c'est que le code est plus compact, mais avoir un delimiteur de fin de bloc explicite n'est pas un mal pour des debutants.

La concurrence est faussée par l'ipr, il est vrai. Peut-être auraient-ils dû communiquer sur les raisons du choix. Ils auraient peut-être convaincu. Après, je reste sur ma position : j'y vois des avantages et des inconvénients à vouloir imposer un langage. Donc on verra ce qu'il en sera par la suite. Mais je ferai quand même l'effort de mon côté d'aller regarder du côté de Xcas.

Vous pouvez regarder des ressources en ligne ici https://www-fourier.ujf-grenoble.fr/~parisse/algoxcas.html
User avatar
parisseVIP++
Niveau 11: LV (Légende Vivante)
Niveau 11: LV (Légende Vivante)
Level up: 69.9%
 
Posts: 1704
Joined: 13 Dec 2013, 16:35
Gender: Not specified

Re: Le Python Graph 90+E sera une appli intégrée dispo en ex

Unread postby Bisam » 20 Apr 2018, 13:40

@parisse :
Tu prêches toujours pour ta paroisse, ce que je peux comprendre, mais tu te fourvoies en pensant que le programme d'algorithmique est fait pour faire des maths !
Dans les programmes de prépa, l'algorithmique sert aussi bien en maths, qu'en physique, en sciences de l'ingénieur et souvent pour le TIPE.
Dans les futurs programmes du lycée, il est prévu que l'algorithmique ne soit pas forcément enseigné par les professeurs de mathématiques, et pas forcément en vu de faire des mathématiques.

Tu as raison de penser que Xcas est plus adapté pour faire des maths, et en particulier travailler avec des expressions et faire du calcul formel (tout comme l'était Maple ou Mathematica à l'époque où on l'enseignait en prépa), mais il n'y a pas que ça dans les cartons.

Les programmes futurs du lycée (enfin, la petite part dont les groupes de travail ont bien voulu parler et que j'ai entendue) envisagent également de la modélisation (mise en équation de physique, de chimie ou de biologie puis résolution approchée et visualisation graphique) et de la simulation probabiliste.
Il existe de nombreuses bibliothèques Python pour faire cela... et il me parait naturel d'enseigner AUSSI l'utilisation des ressources mises à disposition.

Les élèves d'aujourd'hui sont habitués à aller chercher sur Internet pour répondre à la moindre de leur question. Il est logique qu'on leur fasse comprendre qu'il est souvent inutile de réinventer la roue. Dans ce cadre, il ne me paraît pas aberrant de travailler sur les vecteurs (par exemple) d'abord avec des listes (en montrant les limites) puis avec une bibliothèque faite pour cela (par exemple "numpy") voire, pour ceux qui suivraient le module d'algorithmique avancée, en créant ses propres objets...
User avatar
BisamAdmin.
Niveau 15: CC (Chevalier des Calculatrices)
Niveau 15: CC (Chevalier des Calculatrices)
Level up: 47.4%
 
Posts: 5422
Joined: 11 Mar 2008, 00:00
Location: Lyon
Gender: Male
Calculator(s):

Re: Le Python Graph 90+E sera une appli intégrée dispo en ex

Unread postby majestyofgaia » 20 Apr 2018, 15:36

@parisse : merci pour ces précisions. Je comprends mieux la plupart de vos objections, et je vais jeter un oeil au module giacpy.

Il y a juste deux choses sur lesquelles je ne suis pas convaincu : votre argument sur la dichotomie. Pourquoi serait-il indispensable de passer une fonction en argument ? En tant qu'enseignant en mathématiques, ce qui m'intéresse c'est simplement qu'ils comprennent le principe de dichotomie. Donc si je fais :

def f(x) :
return cos(x)

Et que dans le programme principal, dans le if j'écris f(a) * f(m), c'est naturel, et ça fonctionne bien. Pas besoin de passer une fonction en paramètre.

Quant à Casio, pourquoi ne pourraient-ils pas créer des points de coordonnées données ? Sur le Casio basic c'était faisable, je me dis qu'ils trouveront bien une solution !
User avatar
majestyofgaiaVIP+
Niveau 7: EP (Espèce Protégée: geek)
Niveau 7: EP (Espèce Protégée: geek)
Level up: 75%
 
Posts: 104
Joined: 17 Nov 2013, 16:20
Gender: Not specified
Calculator(s):

Re: Le Python Graph 90+E sera une appli intégrée dispo en ex

Unread postby parisse » 20 Apr 2018, 16:41

Bisam wrote:@parisse :
Tu prêches toujours pour ta paroisse, ce que je peux comprendre, mais tu te fourvoies en pensant que le programme d'algorithmique est fait pour faire des maths !
Dans les programmes de prépa, l'algorithmique sert aussi bien en maths, qu'en physique, en sciences de l'ingénieur et souvent pour le TIPE.
Dans les futurs programmes du lycée, il est prévu que l'algorithmique ne soit pas forcément enseigné par les professeurs de mathématiques, et pas forcément en vu de faire des mathématiques.

Je ne comprends pas bien l'argument, l'analyse numerique, les probas et la modelisation, je considere cela comme des maths. Ensuite, c'est normal que je defende mon logiciel surtout quand je vois la facon dont il est ecarte, jamais sur des arguments scientifiques, toujours sur des arguments subjectifs.

Tu as raison de penser que Xcas est plus adapté pour faire des maths, et en particulier travailler avec des expressions et faire du calcul formel (tout comme l'était Maple ou Mathematica à l'époque où on l'enseignait en prépa), mais il n'y a pas que ça dans les cartons.

Les programmes futurs du lycée (enfin, la petite part dont les groupes de travail ont bien voulu parler et que j'ai entendue) envisagent également de la modélisation (mise en équation de physique, de chimie ou de biologie puis résolution approchée et visualisation graphique) et de la simulation probabiliste.

On peut faire de la modelisation avec un logiciel de calcul formel, qui peut le plus peut le moins, sinon Maple et Mathematica auraient ferme boutique depuis longtemps. D'ailleurs le rapport du jury de l'agreg externe de maths indique bien que Xcas est un choix possible pour l'option B (calcul scientifique).

Il existe de nombreuses bibliothèques Python pour faire cela... et il me parait naturel d'enseigner AUSSI l'utilisation des ressources mises à disposition.

Les élèves d'aujourd'hui sont habitués à aller chercher sur Internet pour répondre à la moindre de leur question. Il est logique qu'on leur fasse comprendre qu'il est souvent inutile de réinventer la roue. Dans ce cadre, il ne me paraît pas aberrant de travailler sur les vecteurs (par exemple) d'abord avec des listes (en montrant les limites) puis avec une bibliothèque faite pour cela (par exemple "numpy") voire, pour ceux qui suivraient le module d'algorithmique avancée, en créant ses propres objets...

Je ne pretends pas le contraire, je dis juste que l'utilisation de numpy/scipy pour l'algebre lineaire et le calcul scientifique et matplotlib pour la visualisation est plus compliquee a mettre en oeuvre que Xcas dans le cadre d'un cours de maths de niveau lycee et probablement aussi au niveau CPGE, en tout cas si j'en juge par ce que nos etudiants de L3 sortant de prepas sont capables de produire dans notre cours Introduction a la modelisation numerique a Grenoble.
Je rappelle aussi que je demande juste qu'on continue a laisser chaque enseignant choisir ce qui lui parait le plus pertinent dans le cadre de son cours de maths (j'ai deja precise que pour les futurs cours d'informatique ce n'est pas la meme problematique). C'est quand meme etonnant que de vouloir laisser ce choix suscite de telles reactions. Est-ce que vous avez reellement essaye d'utiliser Xcas? Les decideurs ont-ils des oeilleres?
User avatar
parisseVIP++
Niveau 11: LV (Légende Vivante)
Niveau 11: LV (Légende Vivante)
Level up: 69.9%
 
Posts: 1704
Joined: 13 Dec 2013, 16:35
Gender: Not specified

Re: Le Python Graph 90+E sera une appli intégrée dispo en ex

Unread postby parisse » 20 Apr 2018, 17:00

majestyofgaia wrote:Il y a juste deux choses sur lesquelles je ne suis pas convaincu : votre argument sur la dichotomie. Pourquoi serait-il indispensable de passer une fonction en argument ? En tant qu'enseignant en mathématiques, ce qui m'intéresse c'est simplement qu'ils comprennent le principe de dichotomie. Donc si je fais :

def f(x) :
return cos(x)

Et que dans le programme principal, dans le if j'écris f(a) * f(m), c'est naturel, et ça fonctionne bien. Pas besoin de passer une fonction en paramètre.

Ca veut dire soit qu'il faut declarer f comme variable globale dans une fonction dichotomie ce qui n'est pas tres propre, soit que la dichotomie n'est pas une fonction mais juste une boucle qui n'est pas appelable ensuite depuis une autre fonction, ce qui est assez contraire a l'esprit des nouveaux programmes. En discutant ce probleme a l'IREM de Grenoble, on pense que dans un premier temps il vaut mieux copier la definition de f dans une fonction, comme ici (longeur approchee d'un arc de courbe):
https://www-fourier.ujf-grenoble.fr/~parisse/irem/algolongueur.pdf
Une fois que le concept de fonction est bien compris, on peut passer la fonction f en argument de maniere assez naturelle en ecrivant def dicho(f,a,b,eps): ... puis appel de dicho en 2 temps def f(x): return cos(x)-x puis dicho(f,0,1,0.000001) et non en une seule ligne avec lambda. Ca reste quand meme moins naturel que d'appeler la fonction par dicho(cos(x)-x,0,1,0.000001) si son premier argument est une expression (bon, c'est vrai aussi que si on utilise une expression, l'evaluation est un peu moins naturelle)

Quant à Casio, pourquoi ne pourraient-ils pas créer des points de coordonnées données ? Sur le Casio basic c'était faisable, je me dis qu'ils trouveront bien une solution !

Bien sur qu'ils peuvent le faire, mais ca demande du travail : il faut des instructions pour definir la fenetre graphique, des commandes de trace de points, segments, lignes polygonales voire splines, etc..
Je soupconne que dans un premier temps ils feront comme Numworks, une bibliotheque qui permet juste d'allumer ou eteindre un pixel, le travail pour realiser un algorithme de trace de graphe de fonction est alors bien plus consequent.
User avatar
parisseVIP++
Niveau 11: LV (Légende Vivante)
Niveau 11: LV (Légende Vivante)
Level up: 69.9%
 
Posts: 1704
Joined: 13 Dec 2013, 16:35
Gender: Not specified

Re: Le Python Graph 90+E sera une appli intégrée dispo en ex

Unread postby majestyofgaia » 20 Apr 2018, 19:17

Ca veut dire soit qu'il faut declarer f comme variable globale dans une fonction dichotomie ce qui n'est pas tres propre, soit que la dichotomie n'est pas une fonction mais juste une boucle qui n'est pas appelable ensuite depuis une autre fonction, ce qui est assez contraire a l'esprit des nouveaux programmes.


En effet, je ne définissais pas la dichotomie comme une fonction. Lorsque je parlais des limites de l'autoformation et de mes limites théoriques, on est en plein dedans. Je suis absolument incapable de dire si un programme est propre ou non. De plus, lorsque j'ai lu les programmes (et même tout de suite, en les relisant), j'avais bien vu l'apparition des fonctions, mais pour moi elles étaient au service d'un programme "principal". Ainsi, pour moi la dichotomie était un main et la fonction mathématique était écrite dans une fonction.

Après, s'il faut vraiment créer une fonction dichotomie, ça pourrait donner ça :

https://image.noelshack.com/minis/2018/16/5/1524248052-dicho-3.png

On perd le côté naturel de ma version initiale, mais c'est moins compliqué que de passer une fonction en argument. Après, je ne saurais dire s'il s'agit d'une hérésie pour un programmeur... :(
User avatar
majestyofgaiaVIP+
Niveau 7: EP (Espèce Protégée: geek)
Niveau 7: EP (Espèce Protégée: geek)
Level up: 75%
 
Posts: 104
Joined: 17 Nov 2013, 16:20
Gender: Not specified
Calculator(s):

Re: Le Python Graph 90+E sera une appli intégrée dispo en ex

Unread postby parisse » 20 Apr 2018, 20:21

Ca utilise une expression, mais comme Python n'a pas de type de base pour ca, l'expression est stockee dans une chaine de caracteres, et l'evaluation est une incantation magique pour un eleve lambda (et sans doute aussi pour un enseignant lambda).
Avec un CAS sans utiliser de fonction, pour evaluer une expression ex on utilisera quelque chose du genre ex|x=a ou ex(x=a) ou subst(ex,x=a) c'est moins naturel que d'ecrire f(a), mais pas a ce point. Ca vient aussi du fait que c'est ecrit comme un programme interactif qui appelle la fonction dichotomie, alors qu'il est a mon avis beaucoup plus simple de ne garder que la fonction dichotomie et depuis le shell de definir f puis appeler dichotomie.
En tout cas votre message est tres interessant, ca montre que l'approche "fonction" voulue par les nouveaux programmes ne va pas de soi.
User avatar
parisseVIP++
Niveau 11: LV (Légende Vivante)
Niveau 11: LV (Légende Vivante)
Level up: 69.9%
 
Posts: 1704
Joined: 13 Dec 2013, 16:35
Gender: Not specified

PreviousNext

Return to News Casio

Who is online

Users browsing this forum: No registered users and 8 guests

-
Search
-
Featured topics
Comparaisons des meilleurs prix pour acheter sa calculatrice !
1
-
Donations / Premium
For more contests, prizes, reviews, helping us pay the server and domains...

Discover the the advantages of a donor account !
JoinRejoignez the donors and/or premium!les donateurs et/ou premium !


Partner and ad
Notre partenaire Jarrety 
-
Stats.
369 utilisateurs:
>332 invités
>32 membres
>5 robots
Record simultané (sur 6 mois):
6892 utilisateurs (le 07/06/2017)
-
Other interesting websites
Texas Instruments Education
Global | France
 (English / Français)
Banque de programmes TI
ticalc.org
 (English)
La communauté TI-82
tout82.free.fr
 (Français)