Quelqu'un peut m'expliquer pourquoi cette différence entre les exemples 1 et 3 ?

Eupe pour les devs.

dev js et pas compris non plus

peut-être car 1. n'est pas un chiffre flottant donc ça casse le code

Le 30 décembre 2020 à 14:54:32 lechiendelop a écrit :
On ne va pas faire tes devoirs.

Eupe pour les devs.

Je suis le prof.

L'operateur is est un peu tricky. Je te renvois ici t'auras toutes les infos dont t'as besoin : https://dbader.org/blog/difference-between-is-and-equals-in-python

Parce que quand tu crées un integer dans une certaine plage (je sais plus les bornes mais ça doit aller jusqu'à 256), en fait Python te renvoie une réf vers un tableau préalloué (sans doute pour des raisons de perf). Donc a et b pointent vers la mm zone mémoire dans le cas 1. Ce qui n'est pas le cas 3 où a et b pointent vers deux zones mémoires différentes.

Le lien répond pas vraiment à la question. J'ai bien compris que is compare les objets référencées par des variables. Ma question est pourquoi l'interpréteur python créé deux objets distincts pour des flottants et un seul pour des entiers.

Le 30 décembre 2020 à 15:01:51 JesusKrist a écrit :
Parce que quand tu crées un integer dans une certaine plage (je sais plus les bornes mais ça doit aller jusqu'à 256), en fait Python te renvoie une réf vers un tableau préalloué (sans doute pour des raisons de perf). Donc a et b pointent vers la mm zone mémoire dans le cas 1. Ce qui n'est pas le cas 3 où a et b pointent vers deux zones mémoires différentes.

Ok. Tu as un lien qui explicite ça ?

The current implementation keeps an array of integer objects for all integers between -5 and 256, when you create an int in that range you actually just get back a reference to the existing object.

https://docs.python.org/3/c-api/long.html

Sans doute car ces entiers sont souvent utilisés dans les programmes. C'est sans doute plus rapide à l'exécution que devoir lire des entiers en zone mémoire éparpillées.

Le 30 décembre 2020 à 15:09:55 JesusKrist a écrit :

The current implementation keeps an array of integer objects for all integers between -5 and 256, when you create an int in that range you actually just get back a reference to the existing object.

https://docs.python.org/3/c-api/long.html

Sans doute car ces entiers sont souvent utilisés dans les programmes. C'est sans doute plus rapide à l'exécution que devoir lire des entiers en zone mémoire éparpillées.

Cimer clé. Je suis tombé sur un autre contre-exemple un peu plus bas que cette page. C'est un bordel ce truc.
https://stackoverflow.com/questions/15996984/why-id-function-behaves-differently-with-integer-and-float

Le 30 décembre 2020 à 15:13:41 flanders42 a écrit :

Le 30 décembre 2020 à 15:09:55 JesusKrist a écrit :

The current implementation keeps an array of integer objects for all integers between -5 and 256, when you create an int in that range you actually just get back a reference to the existing object.

https://docs.python.org/3/c-api/long.html

Sans doute car ces entiers sont souvent utilisés dans les programmes. C'est sans doute plus rapide à l'exécution que devoir lire des entiers en zone mémoire éparpillées.

Cimer clé. Je suis tombé sur un autre contre-exemple un peu plus bas que cette page. C'est un bordel ce truc.
https://stackoverflow.com/questions/15996984/why-id-function-behaves-differently-with-integer-and-float

Bof non, t'as juste à retenir que le is fonctionne uniquement pour des petits entiers.

"is" n'est pas fait pour comparer float tout simplement

et encore python s'en sort pas mal, si t'as jamais fais de JS tu n'es pas prêt pour ce qu'il t'attend

Le 30 décembre 2020 à 15:17:54 AtomeVengeur a écrit :
"is" n'est pas fait pour comparer float tout simplement

n'importe quoi, un khey a deja donné la réponse t'aurait pu éviter de t'afficher bêtement

Le 30 décembre 2020 à 15:17:54 AtomeVengeur a écrit :
"is" n'est pas fait pour comparer float tout simplement

Le programme d'informatique que je dois enseigner est plus explicite : pas de test d'égalité entre deux flottants. Juste égalité à epsilon près.

Le 30 décembre 2020 à 15:25:51 wxbougnadire a écrit :

Le 30 décembre 2020 à 15:17:54 AtomeVengeur a écrit :
"is" n'est pas fait pour comparer float tout simplement

n'importe quoi, un khey a deja donné la réponse t'aurait pu éviter de t'afficher bêtement

Donc j'ai tord ?
Si j'ai tord, alors tu peux comparer deux flottants avec "is" ?
Vas-y on te regarde

"is" compare les références, ce n'est pas un test d'égalité. Il y a l'équivalent dans tous les langages

Avec les flottants on a aussi des petites surprises

>>> 1/3 + 1/3 + 1/3 == 3                                                                            
False

Mais ce n'est pas dû à Python mais à la manière dont sont représentés les nombres en binaire.

Sinon is ne compare pas les objets mais les références vers ces objets. Tu peux connaître les références en faisant id(object).

a = 256
b = 256
print(id(a), id(b), id(a) == id(b))
a = 257
b = 257
print(id(a), id(b), id(a) == id(b))

Retourne:

10922656 10922656 True
140356704355696 140356704355472 False

Le 30 décembre 2020 à 15:50:57 Azerban a écrit :
Avec les flottants on a aussi des petites surprises

>>> 1/3 + 1/3 + 1/3 == 3                                                                            
False

Mais ce n'est pas dû à Python mais à la manière dont sont représentés les nombres en binaire.

Sinon is ne compare pas les objets mais les références vers ces objets. Tu peux connaître les références en faisant id(object).

a = 256
b = 256
print(id(a), id(b), id(a) == id(b))
a = 257
b = 257
print(id(a), id(b), id(a) == id(b))

Retourne:

10922656 10922656 True
140356704355696 140356704355472 False

Je suis au point sur IEEE-754. Mais ton dernier exemple est sympa en guise d'illustration.

Mon exemple pour tester l'égalité entre les floats était foireux, je viens de m'en rendre compte. Je voulais dire:

>>> x = 0.1 + 0.1 + 0.1
>>> y = 0.3
>>> x == y

False