J’utilise Python dans un milieu scientifique. Et au contraire 1/2=0 ne fait pas tache. Tout les scientifiques sont habitués à la division entière, j’ai déjà expliqué au-dessus pourquoi. C’est un faux problème. C’est le niveau 0 de l’informatique numérique et c’est la première chose qu’on apprend aux étudiants.
« PEP 238: Changing the Division Operator »
Merci, il y a de bons arguments, et d’autres carrément mauvais, voir que je considère faux. Et si c’était à refaire je préfèrerais sans doute associer un symbole différent à la division entière/euclidienne.
Mais il fait l’erreur éternelle, la voie de la facilité : « But division poses a problem: if the expressions for both arguments happen to have an integral type, it implements floor division rather than true division. »
Son raisonnement est celui-ci :
1/2 ne devrait pas être la troncature de la division des réels 1.0/2.0 donc il faut évaluer la division réelle (dans les deux sens du terme). Mais ici, il admet implicitement qu’il travaille avec des réels. Sa conclusion n’est pas une conclusion, mais son hypothèse de travail, car du moment qu’on parle de de division et de troncature, on parle de réels !
J’ai lu la suite du document, et leur histoire d’unification des types numériques me fait carrément peur. Pourquoi unifier ? Ce n’est pas le cas mathématiquement, un nombre entier a = 1, n’est pas le même objet qu’un nombre réel b = 1,0. Heureusement que Numpy, par la force des choses, continuera à permettre le choix du type. D’ailleurs je me demande comment Numpy pour Python3 implémente la division pour le coup.
[^] # Re: mode avocat du diable
Posté par nicolas . En réponse à la dépêche Python 3.2. Évalué à 2.
J’utilise Python dans un milieu scientifique. Et au contraire 1/2=0 ne fait pas tache. Tout les scientifiques sont habitués à la division entière, j’ai déjà expliqué au-dessus pourquoi. C’est un faux problème. C’est le niveau 0 de l’informatique numérique et c’est la première chose qu’on apprend aux étudiants.
« PEP 238: Changing the Division Operator »
Merci, il y a de bons arguments, et d’autres carrément mauvais, voir que je considère faux. Et si c’était à refaire je préfèrerais sans doute associer un symbole différent à la division entière/euclidienne.
Mais il fait l’erreur éternelle, la voie de la facilité : « But division poses a problem: if the expressions for both arguments happen to have an integral type, it implements floor division rather than true division. » Son raisonnement est celui-ci : 1/2 ne devrait pas être la troncature de la division des réels 1.0/2.0 donc il faut évaluer la division réelle (dans les deux sens du terme). Mais ici, il admet implicitement qu’il travaille avec des réels. Sa conclusion n’est pas une conclusion, mais son hypothèse de travail, car du moment qu’on parle de de division et de troncature, on parle de réels !
J’ai lu la suite du document, et leur histoire d’unification des types numériques me fait carrément peur. Pourquoi unifier ? Ce n’est pas le cas mathématiquement, un nombre entier a = 1, n’est pas le même objet qu’un nombre réel b = 1,0. Heureusement que Numpy, par la force des choses, continuera à permettre le choix du type. D’ailleurs je me demande comment Numpy pour Python3 implémente la division pour le coup.