Topic de flanders42 :

Des mages noirs en python ?

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

https://image.noelshack.com/fichiers/2020/53/3/1609334201-signal-2020-12-29-210247.png

dev js et pas compris non plus :(
peut-être car 1. n'est pas un chiffre flottant donc ça casse le code
On ne va pas faire tes devoirs.

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 :hap:

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 :hap:

"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.

Données du topic

Auteur
flanders42
Date de création
30 décembre 2020 à 14:17:12
Nb. messages archivés
22
Nb. messages JVC
21
En ligne sur JvArchive 399