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

Bah, c'est peut-être parce que ce sont des aménagements qui doivent se mettre en place progressivement d'ici la rentrée 2019. Ils ont donc 2 ans devant eux, donc pourquoi se presser, des fois que ça disparaisse tout seul ? Puis ils ont d'autres chats à fouetter avec la réforme du collège....
Bon, OK, je leur cherche des excuses. Sans neoprof (et sans l'envoi de quelques specimens des éditeurs, et des collègues informés) je n'aurais pas forcément été au courant. Mais du coup, je ne me précipite pas, puisqu'on n'a pas d'information officielle ; je fais surtout quelques aménagements à la marge pour combler les lacunes du collège.

Moi j'ai eu un mail. Ensuite, c'est assez évident qu'il était possible d'avoir des aménagements, année post réforme du collège.

Furby a écrit:Ceci dit,  pour en revenir en même temps au sujet d'origine, vous trouvez ça normal qu'un IPR ne nous ai jamais informé des nouveaux aménagements du programme de seconde ? Perso, j'ai découvert ça sur néoprofs, vers le mois de janvier, grâce à je ne sais plus qui, qui a eu la bonne idée de publier ici le texte sur le projet, puis en juin le texte officiel définitif. On n'a jamais eu un mot de la hiérarchie, même pas une lettre de rentrée pour nous le signaler. Je trouve ça un peu scandaleux.
Après, ça ne m'étonne pas qu'on ne propose aucune formation là-dessus dans ma zone.

Non, ce n'est pas normal, vos IPR n'ont pas fait leur boulot.
Dans mon académie, nous avons reçu les aménagements du programme le jour même de publication au B.O. (04/05). Idem pour le doc sur l'algo (07/07).
Les formations auront lieu avant la fin 2017, mais je ne crois pas que les profs concernés en aient déjà été informés.

Pour reprendre le thème du fil, je serais intéressé par vos avis sur ce parti pris du tout fonctionnel. Tout fonctionnel non au sens du Lisp mais cette volonté, dans le document d'accompagnement comme dans les prises de position citées précédemment, de n'écrire que des fonctions et de limiter leur application à la console. Dans le programme de 2nde il y a quand même écrit "la programmation comme production d'un texte dans un langage informatique", donc je ne vois pas pourquoi on devrait se priver des entrées-sorties, et pourquoi on ne devrait faire que de l'algo et pas de la programmation. Et pour ma part, ce ne sont pas les entrées au début et les sorties à la fin, c'est partout, le côté "boite noire" des sujets de bac est à mon sens une dérive de matheux. Ensuite, toujours dans le programme de 2nde, la notion de fonction n'apparaît qu'à la fin, comment faire le reste sans celle-ci et sans utiliser d'entrées-sorties ? Enfin, nous prenons la suite du Scratch au collège, et là aussi il y a des entrées-sorties.

Prezbo a écrit:Je ne peux pas rentrer dans les détails pour des raisons d'anonymat, mais l'année dernière, certaines formations ont été assurées par des collègues qui  programmaient encore à l'aide d'entrées faites par Input et de sorties à l'aide d'affichage à l'écran, sans avoir intégré la programmation fonctionnelle.

Ce qui n’est pas surprenant puisqu’apparemment il faut traîner sur les réseaux et forums pour être au courant et se former.

Prezbo a écrit:Pour ce qui est des documents d'accompagnement, je suis d'accord avec vous : je ne dirais pas qu'ils sont inutiles et inintéressants, mais ils servent de caution à la hiérarchie intermédiaire. ("Vous vous plaignez de na pas être formés ? Allez sur Eduscol."). Surtout, le travail à faire pour en tirer des activités adaptables aux élèves n'est sans doute pas clairement perçu par leurs rédacteurs.

En effet, ce travail d’adaptation a été écarté (ainsi que les cas de conflits éventuels maths/info sur certaines notions).
Pourtant montrer quelques exemples serait un bon moyen de faire comprendre quelles doivent être les évolutions et les limites de la précédente approche.
A côté de ça, les deux manuels 2017 que j’ai, présentent une part très importante de entrées/traitement/sortie et une rédaction toujours très proche d’Algobox (alors que c’est le mal, voir spoiler), quand Python est utilisé c’est aussi avec input, print et les fonctions font une très timide apparition.
C’est mal parti pour ceux qui espèrent de meilleures pratiques.

« algobox vu par les spécialistes »:

user6043 a écrit:Bonjour,
Le problème est qu'il n'y a toujours pas d'indication de langage de programmation. Doit-on prendre Python ?
Est-ce que le bac sera en langage naturel ?
Bonne nouvelle algobox, dans sa nouvelle version, met en place la notion de fonctions de programmation :-)

Pour Algobox, même si les fonctions font leur entrée, l’utiliser ne semble pas une bonne idée, ni edupython d’ailleurs :

Ce qui exclut Algobox, à mon avis.

— Laurent Chéno (@LC_Paris11) 7 juillet 2017

Voui, mais non …
N’est plus mis à jour. Plus pour ISN que maths en seconde-1re-Term.

— Laurent Chéno (@LC_Paris11) 5 juillet 2017

En outre, je ne voudrais plus trop voir de « print » et de « input » et ça ne semble pas la philosophie d’edupython (ni AmiensPython).

— Laurent Chéno (@LC_Paris11) 5 juillet 2017

user6043 a écrit:De toute façon, on nous annonce une réforme pour 2018-2019
Or ce programme de 2nde ne s'appliquera intégralement qu'en 2019. Donc pas de panique. Çà a le temps de changer d'ici là :-)

Pour ce qui est de changements, difficile d’être optimiste vu le passif.

ben2510 a écrit:Le document pointé par Chéno ne comporte pas de signature.
Sauf à aller voir dans les propriétés du document (où on apprend que Chéno travaille avec un logiciel propriétaire sur un système fermé).

En fait, je n’avais mis en lien que le tweet de la version corrigée mais au départ, L. Chéno en parle là :

J’ai commis ce petit texte pour expliquer pourquoi éviter input/print en python :https://t.co/rQMWFALyqH

Qu’en pensez-vous ?

— Laurent Chéno (@LC_Paris11) 10 septembre 2017

Et voilà la réponse de L. Chéno à Y. Monka concernant les 1° et T° non soumis aux aménagements.

Et pour les 1ères&Tales : Qu'en est-il ? On continue à fonctionner comme avant (entrée/traitement/sortie) ? Bac 2018 ? Bac2019 ?

— Yvan Monka (@mtiques) 10 septembre 2017

On ne change pas les règles du jeu sans prévenir avant. Cela étant, rien n’oblige à faire autre chose que la partie « traitement » ! https://t.co/Xm9xl8kGTZ

— Laurent Chéno (@LC_Paris11) 10 septembre 2017

celinesud a écrit:Finalement, ici, ce sera formation en ligne :
https://disciplines.ac-toulouse.fr/mathematiques/sites/mathematiques/files/se_former/procedure_connexion_parcours_algor-program.pdf

Quelle surprise.

Furby a écrit:Ceci dit,  pour en revenir en même temps au sujet d'origine, vous trouvez ça normal qu'un IPR ne nous ai jamais informé des nouveaux aménagements du programme de seconde ? Perso, j'ai découvert ça sur néoprofs, vers le mois de janvier, grâce à je ne sais plus qui, qui a eu la bonne idée de publier ici le texte sur le projet, puis en juin le texte officiel définitif. On n'a jamais eu un mot de la hiérarchie, même pas une lettre de rentrée pour nous le signaler. Je trouve ça un peu scandaleux.
Après, ça ne m'étonne pas qu'on ne propose aucune formation là-dessus dans ma zone.

Non ce n’est pas normal et oui c’est scandaleux. Tout comme les formations proposées pendant l’année de mise en place et non à l’avance.
Manque de considération pour le travail de préparation et de réflexion, pour les élèves, pour la discipline.

Prezbo a écrit:

neo-fit a écrit:

proba/stat :

Merveilleux.

Claudine Schwartz, statisticienne qui a été apparemment pour beaucoup pour l'introduction des statistiques inférentielles et des simulations de tirages aléatoires au lycée au moment ou elle présidait le groupe chargé de la rédaction des programmes (2000-2003) finit par avouer quinze an après à demi-mots que c'est un échec.

Echec avec lequel on va devoir continuer à vivre, puisque le système semble ne plus être capable d'avouer ses erreurs.

N’est-ce pas !
J’ajoute dans le spoiler ci-dessous, un dernier article de Daniel Perrin.
Les aménagements de seconde sont d’ailleurs revenus sur les conditions d’application de l’intervalle de fluctuation énoncées jusqu’alors et dont parle D. Perrin.

proba/stat :

Comme pour les proba/stats, les erreurs en algo/prog sont « corrigées » sans le crier trop fort mais ces deux expériences entament vraiment la confiance.

Bonjour à tous,

Pardon de m'immiscer dans la conversation, je n'ai pas de secondes depuis des années et n'en ai toujours pas cette année d'ailleurs, et je ne suis sans doute pas bien futée, mais je n'ai pas réussi à comprendre réellement la différence de FOND entre ce qu'on devait faire avant en terme d'algorithme, et ce qu'on doit faire maintenant?

est-ce "juste" la notion de fonction informatique qu'on doit aborder? un langage informatique imposé? (alors qu'avant, seul l'algo comptait)

est-ce que quelqu'un pourrait me dire clairement la différence? (j'ai lu les docs, et notre IPR nous a même envoyé le pgmme de seconde avec "rayé" ce qui n'existe plus, et rajouté "en rouge" les nouveautés, et néanmoins, à part de la com, je n'arrive pas à y déceler le changement de "fond")

Merci beaucoup !

L'article cité ci-dessus répond bien à cette question de la différence de fond me semble-t-il : https://t.co/rQMWFALyqH , même si en pratique je ne suis toujours pas sure de savoir comment je vais m'y prendre en seconde cette année... Je vais commencer par des programmes de calcul, qui permettent de reprendre la démarche algorithmique vue au collège tout en retravaillant le calcul algébrique, le calcul tout court et les équations, mais ensuite, je ne sais pas trop.

VinZT a écrit:Hâtons-nous lentement.

Très.

BrindIf a écrit:L'article cité ci-dessus répond bien à cette question de la différence de fond me semble-t-il : https://t.co/rQMWFALyqH , même si en pratique je ne suis toujours pas sure de savoir comment je vais m'y prendre en seconde cette année... Je vais commencer par des programmes de calcul, qui permettent de reprendre la démarche algorithmique vue au collège tout en retravaillant le calcul algébrique, le calcul tout court et les équations, mais ensuite, je ne sais pas trop.

Merci pour ta réponse

Je dois vraiment être stupide, parce qu'à part dire "maintenant on va faire un programme qu'on va pouvoir réutiliser dans d'autres programmes plutôt qu'un programme "sec"", je ne vois pas de différence de fond :/

précisément en ce qui concerne l'exemple de la primalité du nombre

"avant" on faisait un programme "juste" pour savoir si le nombre était premier ou pas
"maintenant" on fait un programme qui teste la primalité d'un nombre ...qu'on va pouvoir réutiliser à d'autres fins.

je ne vois pas bien ce que ça change ....

Oui, c'est ça. C'est effectivement léger comme changement à mettre en place, tout en étant extrêmement puissant sur le plan conceptuel.

BrindIf a écrit:Oui, c'est ça. C'est effectivement léger comme changement à mettre en place, tout en étant extrêmement puissant sur le plan conceptuel.

Penser en fonctionnel c'est peut-être très puissant, mais je trouve que c'est trop dur pour nos secondes, trop abstrait.
Dans les anciens programmes on faisait du Caml en sup MPSI je crois, mais là on parle de secondes... qui plus est dans un cours de maths et pas d'informatique.

Guermantes729 a écrit:

Je dois vraiment être stupide, parce qu'à part dire "maintenant on va faire un programme qu'on va pouvoir réutiliser dans d'autres programmes plutôt qu'un programme "sec"", je ne vois pas de différence de fond :/

Cela interroge la notion de programme.

Originellement, un programme est exécuté par le biais de l'interface système en ligne de commande. On peut passer des paramètres qui seront utilisés par le programme. Celui-ci effectue les actions qu'il a à faire et renvoie les informations (résultat) via un "print".

Exemple: calcul de 2×9.

Code:

$ wcalc -h -q 2*9
   0x12


Ce résultat peut-être utilisé, bien qu'il résulte d'un "print", par d'autres programmes. C'est le rôle du "pipe" dans les shell, mais on peut aussi passer par des fichiers.

Code:

$ wcalc -h -q 2*9 | tr -d '0x'
   12


C'est la puissance de la philosophie unix: des programmes simples qui ne font qu'une chose mais qui le font bien, qui interagissent entre eux via le shell.

Le print n'est pas une mauvaise façon de renvoyer un résultat. Quand on dit qu'il ne faut pas utiliser le print, on fait quoi? Une fonction qui calcule le PGCD et n'affiche pas le résultat ne peut pas être utilisée seule. Il faut l'inclure dans un programme qui va, lui, afficher le résultat (ou en faire autre chose). Une telle fonction a sa place dans une bibliothèque de programme (library), mais ne constitue pas en soit un programme qui suppose une interaction (avec l'utilisateur ou avec d'autres programmes).

Quand on dit aux lycéens d'utiliser "print", on leur demande d'écrire un programme. Quand on leur demande de ne pas l'utiliser, on leur demande d'écrire une fonction qui sera incluse ensuite dans un programme, d'une façon ou d'une autre. Séparer dans une fonction les algorithmes est une bonne chose en programmation. Mais il faut l'expliquer. Et expliquer pourquoi.

Edit.
J'ajoute qu'on pourrait voir les choses comme ceci: l'algorithmique consiste à écrire les fonctions et la programmation à les utiliser dans des programmes.
Si on veut confier aux professeurs de mathématiques une partie de l'enseignement de l'informatique, il ne peut s'agir que des algorithmes, donc l'écriture des fonctions. Pour le reste, il faudrait le confier à des enseignants d'informatique. Les professeurs de mathématiques ne sont pas compétents pour l'ensemble.

D'accord merci à tous

Je suis d'accord avec ce qui a été dit, je pousserais même le bouchon en disant que la notion de "concept" étant elle-même à peu près incompréhensible à un élève lambda de Seconde, je doute que ce bouleversement là de "concept" les bouleverse, eux :/

je pense que ça nous concerne nous davantage qu'eux. Je pense que dans une classe, il n'y aura rien de nouveau, les "bons" n'auront aucun mal à passer de "écrire une fonction" à "les utiliser dans des programmes" (faciles les programmes faciles...), et les autres n'y comprendront rien. Comme actuellement.

Je m'en retourne à mes TES en attendant que la réforme ne me rattrape En espérant que je vais courir plus vite qu'elle

PS: de toutes les façons, en MPSI, les profs d'info repartent totalement de zéro. Comme les profs de maths, comme les profs de Physique. De ma fenêtre, j'ai l'impression que le 1er mois est là pour "détricoter" toutes les mauvaises habitudes prises par les élèves en terminale...

Live and let die.

Ca m'agace leur histoire de programmation. Ils sont complètement à côté de la plaque dans les hautes sphères.
De toute façon, je ne vois pas l'intérêt de vouloir faire du zèle.

1) les nouvelles progressions dans les échelons  font qu'on n'a plus grand chose à gagner à vouloir être un bon petit soldat ...
2) je ferai le nécessaire uniquement dans l'objectif du Bac quand on y sera (et encore ... à quoi ressemblera le Bac dans 2 ans ?)
3) j'ai une vie et je n'ai aucune motivation pour créer de nouveaux cours et montrer aux TS (qui parfois ont à peine le niveau 3e en maths ...) que programmer c'est trop cool. Yeah ! Vive les h4ck3rs ! \o/

Au pire je me mettrai en retrait des term dans les prochaines années. Secondes et premières après tout, c'st moins de stress au final.

Pfffff quand je pense que j'aimais ce métier il y a quelques années. J'en suis dégoûté par ces programmes.

Le passage aux fonctions, effectivement, ce ne change pas grand chose en apparence mais ça change tout. D'abord parce que c'est beaucoup plus pratique, surtout pour un usage proche des math où on n'a pas envie de coder une interface de saisie ou d'affichage. Également parce que c'est une imprégnation lente d'une façon d'écrire les programmes sur laquelle les années suivantes peuvent construire, au lieu de devoir dire : vous avez appris à faire comme ça au lycée, et bien maintenant on renverse tout.

Ça plusieurs fois que je lis (ça doit être le même collègue en plus) des arguments sur les programmes à la Unix qui travaillent avec les entrées/sorties standard. Et c'est vrai que ça existe et que c'est une façon commode pour la constitution d'un écosystème de programmes qui communiquent entre eux (d'ailleurs j'ai viré Windows pour Linux dans mes salles de TP aussi pour cette raison).

Cependant, je ne suis pas d'accord pour dire qu'un programme doive nécessairement se baser là dessus, surtout s'il s'agit d'opposer un programme à un algorithme. Par opposition à un algorithme, je dirais qu'un programme s'exécute (ou a vocation à s'exécuter) sur une machine. Mais ce n'est pas nécessairement une machine matérielle directement. Le plus souvent, un programme s'exécute au sein d'un système d'exploitation, qu'on peut déjà voir comme une machine virtuelle s'exécutant sur la machine physique. D'ailleurs les entrées/sorties Unix sont possibles grâce à Unix justement. Ou pour reprendre l'argument avec un soupçon d'exagération qu'on voudra bien me passer, un programme à la Unix qui imprime le PGCD de deux nombres non plus ne peut pas être utilisé seul : il faut Unix !

De même, un interpréteur Python est une machine virtuelle et il n'y a pas de raison de se refuser à l'utiliser lorsque c'est pertinent.

Et ça l'est : c'est bien gentil de faire des input et des print, mais ça signifie qu'à chaque fois on doit passer par des chaines de caractères (ou même d'octets) ce qui suppose de savoir parser les entrées. Utiliser des fonctions et les appeler depuis l'interpréteur permet de bénéficier de tout ce qui est fait en standard au niveau syntaxique et sémantique par le langage. Pour prendre un exemple clair : en Python, si on écrit un programme qui demande un entier avec un input et qu'on veut pouvoir saisir "2+3", il faut écrire soi-même un parseur pour analyser cette construction, parce que la fonction de conversion de chaine en entier véritable (int) ne sait convertir que des chaines qui représentent syntaxiquement des entiers (et non des expressions à valeurs entières). Alors que si on appelle une fonction dont un paramètre est entier, on peut faire f(2+3) parce qu'alors on travaille déjà en Python et la sémantique du langage fait que la valeur de 2+3 sera calculée automatiquement et la fonction f appelée avec la valeur 5.

Sans parler même du fait que la production finale d'un programme n'est pas forcément du texte : on peut aussi afficher une représentation graphique.

Par ailleurs, si (et c'est ce qui est demandé) les fonctions informatiques commencent à être, ne disons pas étudiées en tant que telles, mais vues régulièrement, il est judicieux de ne pas se mettre à input/print dès le début. Car en tant que fonctions (informatiques), elles sont très curieuses (puisqu'elles sont fortement impures) : le résultat d'un appel à la fonction input ne dépend pas du tout du paramètre qu'on lui a fourni mais de ce qui est tapé au clavier. Quant à print, ce n'est pas le résultat qu'elle calcule qui nous intéresse (en calcule-t-elle seulement un pour un élève de seconde ?) mais ce qui se passe pendant que ce calcul se fait (l'affichage).

Enfin, un programme à la Unix, à moins d'être particulièrement trivial, est tout de même constitué de fonctions, à l'intérieur. C'est donc un concept utile. Et là je chipote un peu, mais on peut même dire qu'un programme est une fonction (impure) du point de vue du shell : il a bien des paramètres et une valeur de retour, ça ne se voit pas forcément en Python mais c'est très clair en C avec le

Code:

int main(int argc, char** argv)

Et ça retrouve en Python : un programme est une fonction, sauf que le système d'exploitation c'est l'interpréteur Python. Au delà, ça n'a rien de choquant en informatique (plutôt fonctionnelle, pour le coup, ou tout au moins procédurale) d'énoncer tout de go qu'un programme est défini comme une fonction ou une collection de fonctions (voir OCaml, même C en tirant un peu, ou plus théoriquement tout ce qui tourne autour du lambda-calcul et de ses avatars).

Pardon pour cette digression suscitée par les arguments (intéressants) que j'ai lus plus haut. Ça ne fait pas avancer le schmilblik de la situation concrète en seconde (sauf sur un point : non, il n'y a aucune gêne à avoir quand on écrit une fonction qui nécessite l'interpréteur pour être appelée).

Tout ça pour des élèves qui ne sont pas capables de calculer la somme des n premiers entiers avec une boucle.....

C'est un peu comme en BTS où on demande d'étudier le filtrage numérique par convolution avec des étudiants qui confondent addition et multiplication, qui ne sont pas convaincu par le caractère commutatif de ces opérations et qui ignorent l'usage des parenthèses dans la distributivité....cela dit le filtrage numérique est un outil très puissant.
On nage toujours autant sur la tête

Balthazaard a écrit:Tout ça pour des élèves qui ne sont pas capables de calculer la somme des n premiers entiers avec une boucle.....

C'est un peu comme en BTS où on demande d'étudier le filtrage numérique par convolution avec des étudiants qui confondent addition et multiplication, qui ne sont pas convaincu par le caractère commutatif de ces opérations et qui ignorent l'usage des parenthèses dans la distributivité....cela dit le filtrage numérique est un outil très puissant.
On nage toujours autant sur la tête

+10000 malheureusement :/

Balthazaard a écrit:Tout ça pour des élèves qui ne sont pas capables de calculer la somme des n premiers entiers avec une boucle.....

Y a pas besoin de boucle pour ça

Merci...je cherchais un exemple peu traumatisant, on est à l'époque de l'expérimentation....du reste la formule n(n+1)/2 atteint largement les limites supérieures du calcul (parenthèse plus division....)

Balthazaard a écrit:Tout ça pour des élèves qui ne sont pas capables de calculer la somme des n premiers entiers avec une boucle.....

C'est un peu comme en BTS où on demande d'étudier le filtrage numérique par convolution avec des étudiants qui confondent addition et multiplication, qui ne sont pas convaincu par le caractère commutatif de ces opérations et qui ignorent l'usage des parenthèses dans la distributivité....cela dit le filtrage numérique est un outil très puissant.
On nage toujours autant sur la tête

Et je rajouterais "tout ça pour des profs qui ne sont pas capables d'enseigner les rudiments de programmation à leurs élèves..."
Je me mets en tête dans le lot : cette discussion, c'est presque du chinois pour moi:blague: .

Balthazaard a écrit:Merci...je cherchais un exemple peu traumatisant, on est à l'époque de l'expérimentation....du reste la formule n(n+1)/2 atteint largement les limites supérieures du calcul (parenthèse plus division....)

sum([k for k in range(10)]) c'est quand même plus joli que cette vieille formule poussiéreuse, voyons …

Balthazaard a écrit:Merci...je cherchais un exemple peu traumatisant,

J'entends bien ; je plaisante à moitié (je fais aussi cet exemple en prépa pour la même raison), même si ça permet d'illustrer que la question n'est pas tant ici le fond ou la difficulté mathématique de l'activité (je partage assez largement les doutes émis quant aux élèves post college2016, que ce soit pour les math ou la prog) mais la façon dont on le présente.

Je suis un peu extérieur à tout ça mais il me semble que l'évolution du programme de 2nde sur ce point ne demande pas forcément d'aller faire des activités plus poussées sur le fond (et de toutes façons, c'est le professeur dans sa classe qui sait ce qui peut être fait) mais de faire peut-être les même choses, en les abordant d'une façon qui sera compatible avec les approfondissements ultérieurs et non pas en contradiction comme avec le input/print systématique.

Parce que mine de rien (c'est clair bien sûr mais ça fait toujours plaisir d'en avoir une confirmation "de visu"), les élèves retiennent ce qui est fait, un peu. On a vraiment besoin de travailler en sup contre l'habitude de input/print. Et par ailleurs, quand on a un élève dont le(s) professeurs(s) de math on fait très peu voire pas d'algo (ce qui est possible vu que jusqu'à présent c'était des objectifs pour le lycée dont chacun pouvait se dire : ça sera fait après/ça a été fait avant), on s'en rend compte et eux aussi voient qu'ils accrochent moins vite que leurs condisciples (sur les boucles notamment).

VinZT a écrit:

Balthazaard a écrit:Merci...je cherchais un exemple peu traumatisant, on est à l'époque de l'expérimentation....du reste la formule n(n+1)/2 atteint largement les limites supérieures du calcul (parenthèse plus division....)

sum([k for k in range(10)]) c'est quand même plus joli que cette vieille formule poussiéreuse, voyons …

sum(range(10)) suffit.
Par contre tu calcules 0+1+2+3+4+5+6+7+8+9

ben2510 a écrit:

VinZT a écrit:

Balthazaard a écrit:Merci...je cherchais un exemple peu traumatisant, on est à l'époque de l'expérimentation....du reste la formule n(n+1)/2 atteint largement les limites supérieures du calcul (parenthèse plus division....)

sum([k for k in range(10)]) c'est quand même plus joli que cette vieille formule poussiéreuse, voyons …

sum(range(10)) suffit.
Par contre tu calcules 0+1+2+3+4+5+6+7+8+9

Bien sûr, mais celle que j'ai donnée peut s'adapter pour calculer d'autres sommes.
Cela dit, en seconde, l'usage est plus que limité, j'en conviens.

Tu as bien sûr raison, ta forme est généralisable à toutes les sommes de termes f(k).
Cela rejoint les premières remarques sur le fait que 1+2+3+...+n est trop simple à calculer pour nécessiter un algorithme, d'ailleurs.