"/a" is not "/a" ?

  • Thread starter Emanuele D'Arrigo
  • Start date
R

Robert Kern

... answered my own question


class Foo:
def __eq__(self, b):
return False

--> True

--> False

And for a practical, real world example:

In [1]: inf = 1e200 * 1e200

In [2]: inf
Out[2]: inf

In [3]: nan = inf / inf

In [4]: nan
Out[4]: nan

In [5]: nan is nan
Out[5]: True

In [6]: nan == nan
Out[6]: False

--
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
that is made terrible by our own mad attempt to interpret it as though it had
an underlying truth."
-- Umberto Eco
 
R

Robert Kern

As far as I remember that's not correct. It's just the way C has
interpreted the standard and Python inherited the behavior. But you may
proof me wrong on that.

Mark, you are the expert on IEEE 754.

Steven is correct. The standard defines how boolean comparisons like ==, !=, <,
etc. should behave in the presence of NaNs. Table 4 on page 9, to be precise.

--
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
that is made terrible by our own mad attempt to interpret it as though it had
an underlying truth."
-- Umberto Eco
 
L

Lie Ryan

Mel said:
wrote:


Ho-hum. MUDD game.

def broadcast (sender, message):
for p in all_players:
if p is not sender:
p.tell (message) # don't send a message to oneself

Since in a MUD game, a player would always have a unique username, I'd
rather compare with that. It doesn't rely on some internals. There is
very, very rare case where 'is' is really, really needed.
 
L

Lie Ryan

Robert said:
Steven is correct. The standard defines how boolean comparisons like ==,
!=, <, etc. should behave in the presence of NaNs. Table 4 on page 9, to
be precise.

The rationale behind the standard was because NaN can be returned by
many distinct operations, thus one NaN may not be equal to other NaN.
 
M

Mark Dickinson

As far as I remember that's not correct. It's just the way C has
interpreted the standard and Python inherited the behavior. But you may
proof me wrong on that.

Steven's statement sounds about right to me: IEEE 754
(the current 2008 version of the standard, which supersedes
the original 1985 version that I think Robert Kern is
referring to) says that every NaN compares *unordered*
to anything else (including itself). A compliant language is
required to supply twenty-two(!) comparison operations, including
a 'compareQuietEqual' operation with compareQuietEqual(NaN, x)
being False, and also a 'compareSignalingEqual' operation, such
that compareSignalingEqual(NaN, x) causes an 'invalid operation
exception'. See sections 5.6.1 and 5.11 of the standard for
details.

Throughout the above, 'NaN' means quiet NaN. A comparison
involving a signaling NaN should always cause an invalid operation
exception. I don't think Python really supports signaling NaNs
in any meaningful way.

I wonder what happens if you create an sNaN using
struct.unpack(suitable_byte_string) and then try
to do arithmetic on it in Python...

Mark
 
C

Carl Banks

Since in a MUD game, a player would always have a unique username, I'd
rather compare with that. It doesn't rely on some internals. There is
very, very rare case where 'is' is really, really needed.

Well, by that criterion you can dismiss almost anything.

Of course you can assign unique ids to most objects and perform your
identity tests that way. The point is that sometimes you do need to
test for the identity of the object, not merely the equivalent
semantic value.

If, faced with this problem (and I'm guessing you haven't faced it
much) your approach is always to define a unique id, so that you can
avoid ever having to use the "is" operator, be my guest. As for me, I
do program in the sort of areas where identity testing is common, and
I don't care to define ids just to test for identity alone, so for me
"is" is useful.


Carl Banks
 
R

Robert Kern

Steven's statement sounds about right to me: IEEE 754
(the current 2008 version of the standard, which supersedes
the original 1985 version that I think Robert Kern is
referring to)

Yes.

--
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
that is made terrible by our own mad attempt to interpret it as though it had
an underlying truth."
-- Umberto Eco
 
S

Steve Holden

Gary said:
But that definition is the *source* of the trouble. It is *completely*
meaningless to newbies. Until one has experience in programming in
general and experience in Python in particular, the difference between
"object identity" and "value" is a mystery.
So in order to lead newbies away from this *very* common trap they often
fall into, it is still a valid rule to say

Newbies: Never use "is" to compare immutable types.
I think this is addressing the wrong problem. I;d prefer to say

Newbies: never assume that the interpreter keeps just one copy of any
value. Just because a == b that doesn't mean that a is b. *Sometimes* it
will be, but it isn't usually guaranteed.
of even better

Newbies: Never use "is" to compare anything.

This will help them avoid traps, and won't hurt their use of the
language. If they get to a point that they need to contemplate using
"is", then almost be definition, they are not a newbie anymore, and the
rule is still valid.

personally I believe newbies should be allowed the freedom to shoot
themselves in the foot occasionally, and will happily explain the issues
that arise when they do so. It's all good learning.

I think using "is" to compare mutable objects is a difficult topic to
explain, and I think your division of objects into mutable and immutable
types is unhelpful and not to-the-point.

regards
Steve
 
S

Steve Holden

Paul said:
When is it ever necessary to compare for identity?

For example when providing a unique "sentinel" value as a function
argument. The parameter must be tested for identity with the sentinel.

regards
Steve
 
S

Steve Holden

Carl said:
Well, by that criterion you can dismiss almost anything.

Of course you can assign unique ids to most objects and perform your
identity tests that way. The point is that sometimes you do need to
test for the identity of the object, not merely the equivalent
semantic value.

If, faced with this problem (and I'm guessing you haven't faced it
much) your approach is always to define a unique id, so that you can
avoid ever having to use the "is" operator, be my guest. As for me, I
do program in the sort of areas where identity testing is common, and
I don't care to define ids just to test for identity alone, so for me
"is" is useful.
Well, the obvious "identity" is id(p), but then

a is b

is entirely equivalent to

id(a) == id(b)

regards
Steve
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top