I am never going to complain about Python again

Steven D'Aprano steve+comp.lang.python at pearwood.info
Fri Oct 11 05:11:12 EDT 2013


On Fri, 11 Oct 2013 09:17:37 +0100, Joshua Landau wrote:

> On 11 October 2013 03:08, Steven D'Aprano
> <steve+comp.lang.python at pearwood.info> wrote:
>> 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.

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.


-- 
Steven



More information about the Python-list mailing list