>On 2011-06-02, Nobody <nob...@nowhere.com> wrote:
>> (I note that Python actually raises an exception for "0.0/0.0").
In article <isasfm$inl$1...@reader1.panix.com>
Grant Edwards <invalid@invalid.invalid> wrote:
>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.
Indeed -- or at least, inconsistent. (Again I would not mind at
all if Python had "raise exception on NaN-result" mode *as well
as* "quietly make NaN", perhaps using signalling vs quiet NaN to
tell them apart in most cases, plus some sort of floating-point
context control, for instance.)
>> Also, note that the "convenience" of NaN (e.g. not propagating from
>> the untaken branch of a conditional) is only available for
>> floating-point types. If it's such a good idea, why don't we have it
>> for other types?
Mostly because for integers it's "too late" and there is no standard
for it. For others, well:
>>> import decimal
>>> decimal.Decimal('nan')
Decimal("NaN")
>>> _ + 1
Decimal("NaN")
>>> decimal.setcontext(decimal.ExtendedContext)
>>> print decimal.Decimal(1) / 0
Infinity
>>> [etc]
(Note that you have to set the decimal context to one that does
not produce a zero-divide exception, such as the pre-loaded
decimal.ExtendedContext. On my one Python 2.7 system -- all the
rest are earlier versions, with 2.5 the highest I can count on,
and that only by upgrading it on the really old work systems --
I note that fractions.Fraction(0,0) raises a ZeroDivisionError,
and there is no fractions.ExtendedContext or similar.)
>> The definition is entirely arbitrary.
>
>I don't agree, but even if was entirely arbitrary, that doesn't make
>the decision meaningless. IEEE-754 says it's True, and standards
>compliance is valuable. Each country's decision to drive on the
>right/left side of the road is entire arbitrary, but once decided
>there's a huge benefit to everybody following the rule.
This analogy perhaps works better than expected. Whenever I swap
between Oz or NZ and the US-of-A, I have a brief mental clash that,
if I am not careful, could result in various bad things. :-)
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
email: gmail (figure it out) http://web.torek.net/torek/index.html
--
http://mail.python.org/mailman/listinfo/python-list
