Méthodes d'Euler et Runge-Kutta 2
Re: Méthodes d'Euler et Runge-Kutta 2
Oui ça fait longtemps que numpy/scipy/matplotlib non seulement existent pour python3 mais c'est même la version de base depuis déjà longtemps.
Si on code proprement en 2.7 et qu'on ne manipule pas trop de chaines (utf8...) on ne verra pas la différence entre le 3.X et le 2.7.X....sauf sur la division de deux entiers...mais je déconseille fortement d’utiliser implicitement le fait que "int/int" renvoie float un python3 (et un int en python2).
Autre différence qu'on peut peut être voir : le type entier. en 2.7 on a des int puis des long quand ça devient trop grand. En 3, c'est UN seul et unique type entier. C'est plus propre car "changer de type quand on fait +1" bof bof niveau sémantique MAIS ça cache le fait qu'un int qui tiens sur 64 se traite beaucoup plus rapidement qu'un int qui ne tiens plus sur 64bits..
Si on code proprement en 2.7 et qu'on ne manipule pas trop de chaines (utf8...) on ne verra pas la différence entre le 3.X et le 2.7.X....sauf sur la division de deux entiers...mais je déconseille fortement d’utiliser implicitement le fait que "int/int" renvoie float un python3 (et un int en python2).
Autre différence qu'on peut peut être voir : le type entier. en 2.7 on a des int puis des long quand ça devient trop grand. En 3, c'est UN seul et unique type entier. C'est plus propre car "changer de type quand on fait +1" bof bof niveau sémantique MAIS ça cache le fait qu'un int qui tiens sur 64 se traite beaucoup plus rapidement qu'un int qui ne tiens plus sur 64bits..
Pas prof.
Prépa, école, M2, thèse (optique/images) ->ingé dans le privé.
Prépa, école, M2, thèse (optique/images) ->ingé dans le privé.
Re: Méthodes d'Euler et Runge-Kutta 2
Oui, 2013, l'année où a été introduit l'informatique en CPGE. À ce moment les modules nécessaires pour le calcul numérique n'étaient pas tous tout à fait au point pour la version 3.x.x (numpy pour Python3 date de 2010, mais matplotlib de 2012/2013 et encore cela ne fonctionnait pas toujours très bien sous Windows). De nombreux lycée ont donc fait le choix de la version 2.7, ce qui n'a pas nécessairement été changé depuis (et ce n'est pas forcément si simple que cela lorsque l'on a préparé (*) de nombreux supports/modules qu'il faut tous modifier).Ewind a écrit :Ta vidéo date de 2013.
Pour moi l'énorme avantage (**) de la version 3.x.x. c'est le choix de l'encodage UTF-8 par défaut, ce qui est quand même vraiment mieux lorsque l'on doit jongler entre différents systèmes d'exploitation et lire/ouvrir des fichiers.
Par contre je ne vois pas d'inconvénient à assumer que la division renvoie un flottant en python3 (de même que la racine carrée par exemple). Le but de ce changement c'est bien de se simplifier la vie. Il vaudrait mieux que tous les utilisateurs de 2.7 utilisent en préambule
Code : Tout sélectionner
from __future__ import division
(**) Et aussi le fait de pouvoir utiliser des caractères unicode dans les noms de variable, pour le côté amusant.
$ $P = N\!P^* ?$ $
Re: Méthodes d'Euler et Runge-Kutta 2
Oui pour utf8 mais le mieux dans le cadre de la prepa est probablement de ne mettre que de l'ascii partout...même si ca fait vraiment old school.
Disons que pour la division le problème est de SAVOIR ce que ça fait. Comme il y a encore pas mal de python 2.7 dans le monde, on doit expliquer que ca a changé. Le préambule ok ok mais quand ce n'est pas ton code (dans la vraie vie) et que ce code est gros avec des import dans tous les sens...il n'est pas évident de savoir ce que va faire /.
Autre chose : le fait de renvoyer un float n'est pas anodin car ca interdit tout test avec == sur le résultat. Il faut faire passer ce message aux étudiants.
La racine carré? tiens ca a changé entre le 2 et le 3?
Ce dont je me rappelle (en 2 et??? en 3) c'est que sqrt n'est PAS la même fonction selon qu'on la prend de numpy, de scipy ou de python math...donc quand j'ai besoin de sqrt sur les complexe je relis la doc
Disons que pour la division le problème est de SAVOIR ce que ça fait. Comme il y a encore pas mal de python 2.7 dans le monde, on doit expliquer que ca a changé. Le préambule ok ok mais quand ce n'est pas ton code (dans la vraie vie) et que ce code est gros avec des import dans tous les sens...il n'est pas évident de savoir ce que va faire /.
Autre chose : le fait de renvoyer un float n'est pas anodin car ca interdit tout test avec == sur le résultat. Il faut faire passer ce message aux étudiants.
La racine carré? tiens ca a changé entre le 2 et le 3?
Ce dont je me rappelle (en 2 et??? en 3) c'est que sqrt n'est PAS la même fonction selon qu'on la prend de numpy, de scipy ou de python math...donc quand j'ai besoin de sqrt sur les complexe je relis la doc
Pas prof.
Prépa, école, M2, thèse (optique/images) ->ingé dans le privé.
Prépa, école, M2, thèse (optique/images) ->ingé dans le privé.
Re: Méthodes d'Euler et Runge-Kutta 2
Je suis bien d'accord, mais le comportement de python3 est quand même bien plus clair justement (on utilise soit '\' pour les flottants soit '\\' pour les entiers, pas d'ambiguïté possible). En python2 lorsque l'on voit dans un codefakbill a écrit :Disons que pour la division le problème est de SAVOIR ce que ça fait.
Code : Tout sélectionner
a = b / c
Code : Tout sélectionner
a = b // c
Code : Tout sélectionner
a = float(b) / c
En pratique, pour un étudiant travaillant sur python3, le seul problème qu'il pourrait rencontrer c'est copier/coller un code sous python2 qui utiliserait quelque part le fait que a / b est entier, ce qui ne devrait pas exister (il faudrait utiliser '//').
Heu... Dans la "vraie vie" on ne devrait certainement pas aver des imports dans tous les sens... Les imports devraient être regroupés et structurés clairement en en tête de module et de toutes façon from __future__ import doit être la première chose rencontrée (et n'est valable (heureusement !) que dans le module en question). Je ne vois donc aucun moyen de se fourvoyer.fakbill a écrit :Le préambule ok ok mais quand ce n'est pas ton code (dans la vraie vie) et que ce code est gros avec des import dans tous les sens...il n'est pas évident de savoir ce que va faire /.
Oui, mais c'est aussi le cas avec '/' en python2 (qui ne devrait être utilisé que pour des divisions flottantes, même s'il est nécessaire de l'expliciter) en pratique.fakbill a écrit :Autre chose : le fait de renvoyer un float n'est pas anodin car ca interdit tout test avec == sur le résultat. Il faut faire passer ce message aux étudiants.
Je voulais dire que sqrt(4) n'est pas un entier.fakbill a écrit :La racine carré? tiens ca a changé entre le 2 et le 3?
On a un peu dévié du sujet initial...
$ $P = N\!P^* ?$ $
Re: Méthodes d'Euler et Runge-Kutta 2
Heu oui mais tu sais...il y a des TONNES de codes très mal écrits dans la nature...je crois que tu sous estimes ce problème.Heu... Dans la "vraie vie" on ne devrait certainement pas aver des imports dans tous les sens... Les imports devraient être regroupés et structurés clairement en en tête de module et de toutes façon from __future__ import doit être la première chose rencontrée (et n'est valable (heureusement !) que dans le module en question). Je ne vois donc aucun moyen de se fourvoyer.
Sinon oui oui...c'est plus clair en python3 et heureusement
maht.sqrt(4) est un int en python2?? (je n'ai pas python sous la main pour vérifier): si oui c'était vraiment une connerie dans le design du langage.
Pas prof.
Prépa, école, M2, thèse (optique/images) ->ingé dans le privé.
Prépa, école, M2, thèse (optique/images) ->ingé dans le privé.
Re: Méthodes d'Euler et Runge-Kutta 2
Non ! Bien sûr math.sqrt renvoie un flottant quoi qu'il arrive.fakbill a écrit :maht.sqrt(4) est un int en python2?? (je n'ai pas python sous la main pour vérifier): si oui c'était vraiment une connerie dans le design du langage.
"L'enfant est le père de l'homme" (William Wordsworth)
Re: Méthodes d'Euler et Runge-Kutta 2
ha ouf...je ne pouvais pas croire que le BDFL laisse passer un truc pariel!
Pas prof.
Prépa, école, M2, thèse (optique/images) ->ingé dans le privé.
Prépa, école, M2, thèse (optique/images) ->ingé dans le privé.