On 25 Mar 2010, at 07:50 , Alexander Belopolsky wrote:
Since we are now venturing in the realm of python-ideas, I am switching the mailing lists. Please see more below.
On Wed, Mar 24, 2010 at 7:31 PM, Mark Dickinson firstname.lastname@example.org wrote:
On Wed, Mar 24, 2010 at 11:11 PM, Alexander Belopolsky email@example.com wrote:
On Wed, Mar 24, 2010 at 7:02 PM, Mark Dickinson firstname.lastname@example.org wrote: ..
So if I understand correctly, you propose that float('nan') == float('nan') return True. Would you also suggest extending this behaviour to Decimal nans?
Okay. So now it seems to me that there are many decisions to make:
I maybe show my ignorance, but I don't see the significance of bringing Decimal nans to the discussion. My answers below apply equally to binary and decimal floating point numbers.
should any Decimal nan compare equal to any other?
What if the two nans have different payloads or signs?
They are still equal. Just as 0.0 and -0.0 are now.
Excuse me but NaNs propagate right? So we'd have not only float('nan') == float('nan'), but also float('nan') = float('nan') + 1 right? Indeed, any operation on a NaN would return a result equal (and identical?) to itself. I'm not sure that makes more sense than the current behavior (which is at least standard and specified).
IEEE standards were developed in a different problem domain: hardware or low level programming language design.
I don't really agree. They were developed in a problem domain of mapping abstract mathematical concepts to computing. And it's not like they're static and never updated (indeed, IEEE-754 was updated in 2008, if anyone has an IEEE login it would be possible to check the purposes and assumptions the standard set for itself).
I believe changing the behavior of nan to have "nan == nan" would be broken, nan is not a "normal" value (or set of values) of the space.
Having the option of getting an exception upon getting a nan on the other hand (as the default behavior even, with a switch to the current behavior using contexts similar to decimal's), why not.
It's interesting that Bertrand starts from
I am talking about a value, as in mathematics, not an expression, as in programming
but doesn't seem to consider that, in the first place, the very concept of NaN is due to the limitations of physical space compared to the abstract mathematical concepts involved. The very idea of IEEE-754 floats are a a definite departure from the fundamental laws of mathematics, making Bertrand's final request
It is rather dangerous indeed to depart from the fundamental laws of mathematics.
very weird. Unless you remove floats from your language, you're not dealing with grounds mathematics cover in the first place, you're dealing with a concretization of mathematical ideas, and as all changes in abstraction levels, it will leak one way or another.
I'd support "fixing" nan behaviors, but not by making operations on nan reflexive (and nan a normal value, which it isn't) and instead by treating all of them as errors, the same way calling an arbitrary attribute no None results in an AttributeError in Python.