On 2011-06-03, Nobody <nob...@nowhere.com> wrote:
>>> This would produce the same end result as raising an exception
>>> immediately, but would reduce the number of isnan() tests.
>>
>> I've never found the number of isnan() checks in my code to be an
>> issue -- there just arent that many of them, and when they are there,
>> it provides an easy to read and easy to maintain way to handle things.
>
> I think that you misunderstood. What I was saying here was that, if you
> wanted exception-on-NaN behaviour from Python, the interpreter wouldn't
> need to call isnan() on every value received from the FPU, but rely upon
> NaN-propagation and only call it at places where a NaN might disappear
> (e.g. comparisons).
Ideed, I did misunderstand. I thought you were talking about a
the value of reducing the number of isnan() tests in user application
code.
>>> I mean undefined, in the sense that 0/0 is undefined
>>
>> But 0.0/0.0 _is_ defined. It's NaN. ;)
>
> Mathematically, it's undefined.
True, but we must be careful not to confuse math and scientific
calculation using fixed-length binary floting point.
>> IMHO, that's a bug. IEEE-754 states explicit that 0.0/0.0 is NaN.
>> Pythons claims it implements IEEE-754. Python got it wrong.
>
> But then IEEE-754 considers integers and floats to be completely
> different beasts, while Python makes some effort to maintain a
> unified "numeric" interface. If you really want IEEE-754
> to-the-letter, that's undesirable, although I'd question the choice
> of Python in such situations.
Python's minor issues with IEEE-754 are far outweighed by advantages
in other areas. :)
>>> If anything, it has proven to be a major nuisance. It takes a lot of
>>> effort to create (or even specify) code which does the right thing in
>>> the presence of NaNs.
>>
>> That's not been my experience. NaNs save a _huge_ amount of effort
>> compared to having to pass value+status info around throughout
>> complex caclulations.
>
> That's what exceptions are for. NaNs probably save a huge amount of
> effort in languages which lack exceptions, but that isn't applicable
> to Python.
How do you obtain using exceptions a behavior that's the same as with
quiet NaNs?
>>>> The correct answer to "nan == nan" is to raise an exception,
>>>> because you have asked a question for which the answer is nether True
>>>> nor False.
>>>
>>> Wrong.
>>
>> That's overstating it.
It was an attempt to illustate the overstatement to which it was a
reply.
--
Grant Edwards grant.b.edwards Yow! You should all JUMP
at UP AND DOWN for TWO HOURS
gmail.com while I decide on a NEW
CAREER!!
--
http://mail.python.org/mailman/listinfo/python-list
