A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2010-March/098903.html below:

[Python-Dev] Why is nan != nan?

[Python-Dev] Why is nan != nan? [Python-Dev] Why is nan != nan?Raymond Hettinger raymond.hettinger at gmail.com
Thu Mar 25 17:03:04 CET 2010
On Mar 25, 2010, at 4:22 AM, Nick Coghlan wrote:

> Mark Dickinson wrote:
>> Here's an interesting recent blog post on this subject, from the
>> creator of Eiffel:
>> 
>> http://bertrandmeyer.com/2010/02/06/reflexivity-and-other-pillars-of-civilization/
> 
> Interesting. So the natural tweak that would arise from that perspective
> is for us to restore reflexivity by declaring that any given NaN is
> equal to *itself* but not to any other NaN (even one with the same payload).
> 
> With NaN (in general) not being interned, that would actually fit the
> idea of a NaN implicitly carrying the operation that created the NaN as
> part of its definition of equivalence.
> 
> So, I'm specifically putting that proposal on the table for both float
> and Decimal NaNs in Python:
> 
>  "Not a Number" is not a single floating point value. Instead each
>  instance is a distinct value representing the precise conditions that
>  created it. Thus, two "NaN" values x and y will compare equal iff they
>  are the exact same NaN object (i.e. "if isnan(x) then x == y iff
>  x is y".
> 
> As stated above, such a change would allow us to restore reflexivity
> (eliminating a bunch of weirdness) while still honouring the idea of NaN
> being a set of values rather than a single value.
> 

+1


Raymond
More information about the Python-Dev mailing list

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4