Question Python [Maths]

Je croyais avoir à peu près compris le "range" ...

Mais voilà, je viens de vérifier un détail pour demain et l'incompréhension me rattrape (je fais du python à reculons ...)

Pourquoi ceci :

for i in range(0,4) :
u=i**i
print(u)

me donne :
1
1
4
27

une explication pour le 1er "1" ?

Je suis nulle ...

u**n correspond à «u puissance n». Tu calcules donc :
0 puissance 0 = 1 (convention usuelle)
1 puissance 1 = 1
2 puissance 2 = 4
3 puissance 3 = 27

Remarque : tu devrais utiliser la balise code pour ton programme, cela permet de conserver l'indentation, qui est essentielle lorsqu'on lit du code Python :

Code:


for i in range(0,4):
    u = i**i
    print(u)


Ben... c'est pas juste 0^0 ?
Edit : nous sommes d'accord.

Oups .... mea culpa ...
Je ne sais pas pourquoi, j'avais 0² dans ma tête ... fatiguée je suis ...

Désolée du dérangement !

BR a écrit:u**n correspond à «u puissance n». Tu calcules donc :
0 puissance 0 = 1 (convention usuelle)

La convention n'est tout de même pas si évidente :

https://fr.wikipedia.org/wiki/Z%C3%A9ro_puissance_z%C3%A9ro

Mais c'est bien un problème de convention mathématique, pas de programmation.

Prezbo a écrit:

BR a écrit:u**n correspond à «u puissance n». Tu calcules donc :
0 puissance 0 = 1 (convention usuelle)

La convention n'est tout de même pas si évidente :

https://fr.wikipedia.org/wiki/Z%C3%A9ro_puissance_z%C3%A9ro

Mais c'est bien un problème de convention mathématique, pas de programmation.

Oui oui, convention qu'on "évite" en général au collège.

Tiens puisqu'on parle de python, j'ai cru comprendre en discutant avec des collègues (je n'ai pas accès à la base) que pas mal d'algorithmes des sujets E3C techno étaient largement vérolés : indentations incorrectes, deux points manquants, return en dehors d'une fonction, x³ écrit au lieu de x**3 etc.

Ça promet !

VinZT a écrit:Tiens puisqu'on parle de python, j'ai cru comprendre en discutant avec des collègues (je n'ai pas accès à la base) que pas mal d'algorithmes des sujets E3C techno étaient largement vérolés : indentations incorrectes, deux points manquants, return en dehors d'une fonction, x³ écrit au lieu de x**3 etc.

Ça promet !

J'en ai vu passé des hilarants, mais a priori c'est corrigé au fur et a mesure.
Cela dit quand on laisse passer des énormités pareil dans un sujet de bac, on se demande ce que ça donne en classe.

chmarmottine a écrit:

Mais voilà, je viens de vérifier un détail pour demain et l'incompréhension me rattrape (je fais du python à reculons ...)

On sent effectivement que les concepteurs traitent Python depuis trois ans déjà ou pas...

VinZT a écrit:Tiens puisqu'on parle de python, j'ai cru comprendre en discutant avec des collègues (je n'ai pas accès à la base) que pas mal d'algorithmes des sujets E3C techno étaient largement vérolés : indentations incorrectes, deux points manquants, return en dehors d'une fonction, x³ écrit au lieu de x**3 etc.

Ça promet !

D'un autre côté j'imagine assez bien le problème des auteurs : dans quinze jours vous devez donner un sujet complet et original portant sur . . .
Il est facile de les critiquer, mais ferriez vous vraiment mieux ?

Ce n'est pas tant les auteurs que je critique que les relecteurs et « certificateurs » de ces fameux sujets, au premier rang desquels devraient se trouver des ipéhères et des igés, à moins que la besogne leur paraisse trop triviale pour leurs esprits supérieurs.

S'ils n'ont rien trouvé à redire, c'est qu'ils sont encore moins compétents en python que nous autres, soutiers de base, ou bien qu'ils s'en fichent. Après tout, ce sont des séries techno, hein, c'est pas bien grave

Que tout cela ait été pondu dans l'urgence, c'est l'évidence même, mais pas un de ces fonctionnaires zélés pour dire : « stop, on ne sera jamais prêts, tout ceci finira en eau de boudin » ? Sérieusement, à quoi servent-ils ?

A propos de relecture, savez vous que, d'après un document d'accompagnement sur Eduscol pour la classe de seconde

Encadrement de racine de 2 à 10**{-2} près: 1.420000000000001 1.430000000000001

Document publié depuis au moins 3 mois (indication sur la page : «Programmes et ressources en mathématiques» sur Eduscol : mis à jour le 03 octobre 2019). Visiblement ni relu avant publication, ni relu après : personne n'a-t-il relevé l'erreur et contacté Eduscol depuis la mise en ligne ?
D'ailleurs, les documents publiés le sont à la fois au format Jupyter Notebook et sous forme de simple fichier Python... une grande partie des fichiers Python publiés ne fonctionnant pas, car faisant appel à des librairies spécifiques à Jupyter.

C'est pourtant le B.A.BA de l'Informatique : ne jamais publier du code sans l'avoir testé au moins une fois. Ici, c'est simple : ouvrir le fichier Python avec un shell minimal (disons Idle), exécuter, constater que Python se fâche tout rouge...

Bah faut voir le côté positif de la chose, c'est un encadrement à 10^-2 près.
Faux, mais un encadrement quand même.

De toutes façons la plupart (voire tous) des ipéhères que j'ai croisés dans ma contrée lointaine ont une maîtrise de l'informatique assez relative (j'euphémise à mort). Ce sont les mêmes comiques troupiers qui t'enjoignent de différencier alors qu'ils ne faisaient que du magistral quand ils étaient profs.

Pour ce qui est de Jupyter, je me demande bien pourquoi on en parle, j'imagine que c'est encore la lubie du « pas de print » qui est à l'œuvre. Il y aura donc les collègues qui auront vu en formation IDLE, ceux qui auront vu Pyzo, ceux qui auront vu Spyder, ceux qui auront vu Edupython, ceux qui auront vu Jupyter … et les élèves dans tout ça seront largement largués …
Et pour avoir vu les collègues et les élèves à l'œuvre, passer d'un environnement à l'autre n'a rien d'anodin.

BR a écrit:A propos de relecture, savez vous que, d'après un document d'accompagnement sur Eduscol pour la classe de seconde

Encadrement de racine de 2 à 10**{-2} près: 1.420000000000001 1.430000000000001

Document publié depuis au moins 3 mois (indication sur la page : «Programmes et ressources en mathématiques» sur Eduscol : mis à jour le 03 octobre 2019). Visiblement ni relu avant publication, ni relu après : personne n'a-t-il relevé l'erreur et contacté Eduscol depuis la mise en ligne ?
D'ailleurs, les documents publiés le sont à la fois au format Jupyter Notebook et sous forme de simple fichier Python... une grande partie des fichiers Python publiés ne fonctionnant pas, car faisant appel à des librairies spécifiques à Jupyter.

C'est pourtant le B.A.BA de l'Informatique : ne jamais publier du code sans l'avoir testé au moins une fois. Ici, c'est simple : ouvrir le fichier Python avec un shell minimal (disons Idle), exécuter, constater que Python se fâche tout rouge...

Il y a point important dont on parle peu, c'est qu'en plus d'avoir introduit un peu d'algo/prog, on a introduit de l'analyse numérique.
Sans jamais le dire, sans qu'il y ait de remarque dans les programmes ou documents ressources et dans le fond sans aucune réflexion.

L'analyse numérique, c'est loin d'être simple même pour les choses "basiques", il y a plein de précautions à prendre, il faut avoir les idées claires sur les approximations en jeu, sur les maths et sur l'informatique.

Plutôt que se dire que ce n'est en rien à la portée d'élève de seconde, on préfère se dire qu'on peut traiter les flottants comme des entiers (ou des réels..) et faire un peu n'importe quoi à l'arrache. Alors que s'il n'y avait qu'une seule chose à enseigner aux élèves sur le lien entre maths et programmation, c'est qu'il faut être très précis sur la prise en compte des erreurs dès qu'on touche à l'analyse numérique, et là on fait tout le contraire.

(cela dit l'erreur est beaucoup plus trivial ici..)

Et avant de faire de l'analyse numérique combinée avec de la programmation et de la virgule flottante (où les opérations ont des propriétés surprenantes: l'addition n'est pas associative, par exemple), il faudrait déjà commencer par faire de l'analyse numérique simple comme sujet d'étude. Il y a les encadrements en 6e, que l'on pourrait poursuivre par l'enseignement de la racine carrée posée en 5e/4e, après lequel divers approfondissements sont possibles: puissances fractionnaires, balayage décimal sur une fonction monotone, puissances réelles par exemple. Et en faisant de l'analyse numérique tous les ans les élèves seraient mieux armés pour aborder les dérivées autrement que comme une formule magique.
Bonus: enseigner la racine carrée posée et fournir les tables de trigo permet techniquement de dégager les calculatrices du collège .

Simeon a écrit:Il y a point important dont on parle peu, c'est qu'en plus d'avoir introduit un peu d'algo/prog, on a introduit de l'analyse numérique.
Sans jamais le dire, sans qu'il y ait de remarque dans les programmes ou documents ressources et dans le fond sans aucune réflexion.

L'analyse numérique, c'est loin d'être simple même pour les choses "basiques", il y a plein de précautions à prendre, il faut avoir les idées claires sur les approximations en jeu, sur les maths et sur l'informatique.

Je plussoie. Par exemple, le premier algorithme proposé dans les programmes de seconde est justement l'approximation de racine(2) par balayage (présenté dans le document d'accompagnement que j'ai cité). Si on le programme de façon basique avec Python, on tombe d'emblée sur des difficultés liés à la représentation informatique des nombres; et il n'y a pas de méthode claire pour résoudre le problème. Exemple :

Code:

def racine_2(n):
   """
   Paramètre
   ---------
   n : entier
   
   Résultat
   --------
   u : valeur approché de racine(2) par défaut
       à 10**(-n) près
   """
   u, pas = 1, 10**(-n)
   v = u+pas
   while v**2 <= 2:
       u, v = v, v+pas
   return u

On s'attend à obtenir 1.4142 lorsqu'on calcule racine_2(4), 1.41421 lorsqu'on calcule racine_2(5), et pourtant :

Code:

>>> racine_2(4)
1.4141999999999544

>>> racine_2(5)
1.4142100000027136

Bonne chance pour expliquer le problème aux élèves si on ne comprend pas la cause du problème :-)

On peut cacher le souci en arrondissant systématiquement lorsqu'on renvoie le résultat (ou, mieux : dans la boucle), mais le code est beaucoup moins naturel. Et il faut de toutes façons se préparer à répondre à la question : Pourquoi arrondir à n décimales un nombre décimal à n décimales ? Cela ne devrait pas changer ce nombre, donc c'est inutile.

Code:

def racine_2(n):
    """
    Paramètre
    ---------
    n : entier
    
    Résultat
    --------
    u : valeur approché de racine(2) par défaut
        à 10**(-n) près
    """
    u, pas = 1, 10**(-n)
    v = u+pas
    while v**2 <= 2:
        u, v = v, v+pas
    return round(u, n)

J'ai lu ce qui précède et j'ai procédé à ce petit test :

Code:

v = 1
pas=0.1
v = v+pas
print(v)
v = v+pas
print(v)

J'obtiens l'affichage suivant :

Code:

1.1
1.2000000000000002

Je n'ai pas plus cherché que ça ...
Quelqu'un peut-il m'expliquer ?

De toutes manières le premier code n'est pas naturel pour un élève lambda de seconde (je passe sous silence le coup des affectations en parallèle alors qu'on est pas censé faire du python pythonnant). L'élève lambda se contentera de recopier le code. Et le professeur courra aux quatre coins de la salle pour affronter la série de « m'sieu ça marche pas chez moi » et s'esquintera les yeux pour détecter les deux points qui manquent, les indentations mal foutues, les variables dont les noms changent et autres joyeusetés. Pour le reste, je suis d'accord avec toutes vos remarques concernant le notion d'analyse numérique et de représentation des nombres réels. On jette un voile pudique sur ces problèmes alors qu'ils sont réels.

Jobena a écrit:J'ai lu ce qui précède et j'ai procédé à ce petit test :

Code:

v = 1
pas=0.1
v = v+pas
print(v)
v = v+pas
print(v)

J'obtiens l'affichage suivant :

Code:

1.1
1.2000000000000002

Je n'ai pas plus cherché que ça ...
Quelqu'un peut-il m'expliquer ?

Vade retro Satanas ! Les print c'est mal !

Tu es justement tombé sur un problème de représentation des nombres décimaux par un ordinateur. Pour faire simple (en espérant ne pas trop raconter de conneries, les experts me contrediront le cas échéant), un ordinateur manipule des flottants qui sont des sommes de puissance de 2 (positives ou négatives). Pour les nombres entiers, pas de problème. Mais 0.1 ne peut s'écrire comme somme de puissances de 2. Python choisira donc le flottant le plus proche, ce qui donne lieu à des affichages parfois surprenants.

Code:


>>> 0.3-0.2-0.1
-2.7755575615628914e-17


C'est un comportement qu'on retrouve dans presque tout les langages de programmation.

Cela vient du fait que les nombres sont représentés en "binaire", et de la même façon que certains nombres ne sont pas décimaux, certains ne sont pas dyadiques, c'est à dire qu'ils peuvent pas s'écrire sous la forme  a / 2^b.

C'est le cas par exemple de 0,1 qui n'est pas dyadique, 0,1 en base 2 donnerait:
0,00011001100110011... ce développement étant infini, on ne peut en garder en mémoire qu'une partie, il y a donc une approximation et donc si on fait en Python (ou autre), on obtient:

Code:


>>> 0.1 + 0.1 + 0.1
0.30000000000000004


C'est un phénomène "normal" qui peut être contrôlé ou évité de différentes façon, l'expliquer aux élèves ou expliquer les méthodes de contrôles ou d'évitement est cependant assez subtile et prend beaucoup de temps.

J'ai tendance à conseiller d'éviter de travailler avec les flottants en maths pour résoudre ce problème.

(j'ai redis la même chose que VinZT, mais bon le message était déjà tapé, et j'en profite pour militer sur l'usage de dyadique)

Simeon a écrit:J'ai tendance à conseiller d'éviter de travailler avec les flottants en maths pour résoudre ce problème.

… et donc de ne pas faire les trois-quarts des algorithmes proposés dans les programmes

VinZT a écrit: Pour le reste, je suis d'accord avec toutes vos remarques concernant le notion d'analyse numérique et de représentation des nombres réels. On jette un voile pudique sur ces problèmes alors qu'ils sont réels.

Je ne suis pas d'accord. Ces problèmes ne sont par réels : ils sont représentés par des nombres en virgule flottante.

Jobena a écrit:J'ai lu ce qui précède et j'ai procédé à ce petit test :

Code:

v = 1
pas=0.1
v = v+pas
print(v)
v = v+pas
print(v)

J'obtiens l'affichage suivant :

Code:

1.1
1.2000000000000002

Je n'ai pas plus cherché que ça ...
Quelqu'un peut-il m'expliquer ?

Les nombres réels à virgule flottante manipulé par Python sont des nombres codés en binaire. On peut accéder au nombre associé à un flottant x en utilisant la méthode hex()

Code:


>>> 0.1.hex()
'0x1.999999999999ap-4'


0.1 est donc codé par le nombre m*2**(-4) où la mantisse m a pour développement hexadécimal 1.999999999999a (a correspond à 10, b à 11 etc jusque f = 15 en hexadécimal). La dernière décimale binaire a été arrondie par excès, comme lorsqu'on arrondit en base 10 2/3 = 0.6666666.... qui est arrondi au plus proche à 0.6666667.

Le développement binaire de l'entier de développement hexadécimal 1999999999999a est :

Code:


>>> bin(eval('0x1999999999999a'))
'0b11001100110011001100110011001100110011001100110011010


Le développement binaire de 0.1 est donc :

Code:


   0.00011001100110011001100110011001100110011001100110011010'


On recopie le développement binaire correspondant à la mantisse, en plaçant le premier 1 au 4-ième chiffre après la virgule (cela correspond à l'exposant binaire).

L'addition se fait en binaire, arrondie au plus proche. En posant l'addition de 1 et 0.1 en binaire et en mettant __ lorsqu'on dépasse la précision autorisé par les flottants sur 64 bits, on obtient :

Code:


  1.0000000000000000000000000000000000000000000000000000____
+ 0.00011001100110011001100110011001100110011001100110011010
------------------------------------------------------------
  1.0001100110011001100110011001100110011001100110011010____


Les décimales binaires ignorées sont 1010, donc en arrondissant au plus proche, le résultat est arrondi par excès.
La représentation décimale du résultat reste cependant 1.1 :-)

En ajoutant à nouveau 0.1, les décimales binaires ignorées sont à nouveau 1010, on arrondit à nouveau par excès, et la représentation décimale du résultat dépasse 1.2.

BR a écrit:
Les décimales binaires ignorées sont 1010, donc en arrondissant au plus proche, le résultat est arrondi par excès.
La représentation décimale du résultat reste cependant 1.1 :-)

En ajoutant à nouveau 0.1, les décimales binaires ignorées sont à nouveau 1010, on arrondit à nouveau par excès, et la représentation décimale du résultat dépasse 1.2.

Il faudrait préciser : j'entend par 1.1 non pas le vrai nombre 1.1 (qui n'a pas de représentation exacte en base 2) mais le flottant associé (ie : le développement binaire tronqué, arrondi au plus proche). Comme vous voyez, c'est simple :-)