I am never going to complain about Python again

[Steven D'Aprano]

False

Did you maybe accidentally rebind abs? If not, what version of Python are
you using?


[steve@ando ~]$ for a in 2.4 2.5 2.6 2.7 3.2 3.3 ; do

python$a -c "print( 5.0 == abs(3 + 4j) )" ;
done

True
True
True
True
True
True

 

[John Ladasky]

I'd like an argument, please.

'Receptionist' (Rita Davies) - Yes, sir?
'Man' (Michael Palin) - I'd like to have an argument please.
'Receptionist' - Certainly sir, have you been here before...?
'Man' - No, this is my first time.
'Receptionist' - I see. Do you want to have the full argument, or were you thinking of taking the course?
'Man' - Well, what would be the cost?
'Receptionist' - Yes, it's one pound for a five-minute argument, but only eight pounds for a course of ten.
'Man' - Well, I think it's probably best if I start with the five-minute one and see how it goes from there. OK?
'Receptionist' - Fine - I'll see who's free at the moment...Mr.Du-Bakey's free, but he's a little bit concilliatory...Yes, try Mr.Barnard - Room 12.
'Man' - Thank you.

:^)

 

[Joshua Landau]

Your mistake here seems to be that you're assuming that if two numbers
are equal, they must be in the same domain, but that's not the case.
(Perhaps you think that 0.0 == 0+0j should return False?) It's certainly
not the case when it comes to types in Python, and it's not even the case
in mathematics. Given:

x ∈ â„, x = 2 (reals)
y ∈ ℕ, y = 2 (natural numbers)

we have x = y, but since 1/y is undefined (there is no Natural number
1/2), 1/x != 1/y.

Surely 1/y is perfectly well defined, as only y, not 1/y, is
constrained to the natural numbers.

 

[Steven D'Aprano]

Surely 1/y is perfectly well defined, as only y, not 1/y, is constrained
to the natural numbers.

Context is important, and usually implied. 1/y within the natural numbers
is treated in the same way as sqrt(-1) within the reals. Try it on your
calculator, and chances are very good you'll get an error. Try it in
Python 2, or nearly any other programming language (but not Python 3),
and again, chances are you'll get an error.

If you implicitly decide to promote entities, then of course you can
promote y to a real then take the invoice. But that trick still doesn't
work for the original example, int(0.0) == int(0+0j) because promoting 0
to complex doesn't help, you have to demote 0+0j to real and that's
ambiguous.

 

[Neil Cerutti]

Did you maybe accidentally rebind abs? If not, what version of
Python are you using?

Honestly, I think I got my Python term and my Vim term mixed up.
I Shall not post technical stuff while working on other thing.

 

[Roy Smith]

'Receptionist' (Rita Davies) - Yes, sir?
'Man' (Michael Palin) - I'd like to have an argument please.
'Receptionist' - Certainly sir, have you been here before...?
'Man' - No, this is my first time.
'Receptionist' - I see. Do you want to have the full argument, or were you
thinking of taking the course?
'Man' - Well, what would be the cost?
'Receptionist' - Yes, it's one pound for a five-minute argument, but only
eight pounds for a course of ten.
'Man' - Well, I think it's probably best if I start with the five-minute one
and see how it goes from there. OK?
'Receptionist' - Fine - I'll see who's free at the moment...Mr.Du-Bakey's
free, but he's a little bit concilliatory...Yes, try Mr.Barnard - Room 12.
'Man' - Thank you.

:^)

Well, that was half of the joke. I'm waiting to see if anybody gets the
other half.

 

[Joshua Landau]

Context is important, and usually implied. 1/y within the natural numbers
is treated in the same way as sqrt(-1) within the reals.

I don't know; a rational tends to be described as any number of the
form x/y where x, y ∈ ℕ. Hence I don't agree that it's reasonable to
ever assume that 1/y has to exist in the same space as y unless
explicitly stated or generally working within, say, the integers.
Neither of those are remotely true of Python so I don't see how this
point is relevant when discussing Python's concept of equality.

Try it on your
calculator, and chances are very good you'll get an error. Try it in
Python 2, or nearly any other programming language (but not Python 3),
and again, chances are you'll get an error.

*Remains unconvinced.* None of that seems to actually matter.

If you implicitly decide to promote entities, then of course you can
promote y to a real then take the invoice.

I'm not. I'm just not applying the restrictions on y to the function it's in.

But that trick still doesn't
work for the original example, int(0.0) == int(0+0j) because promoting 0
to complex doesn't help, you have to demote 0+0j to real and that's
ambiguous.

I agree on this. The correct interpretation of

0.0 == 0 + 0j

is, of course

complex(0.0) == 0 + 0j