Thanks so much Ben for documenting all these examples. I've been frustrated
by the inconsistencies, but hasn't realized all of those you note.
It would be a breaking change, but I'd really vastly prefer if almost all
of those OverflowErrors and others were simply infinities. That's much
closer to the spirit of IEEE-754.
The tricky case is 1./0. Division is such an ordinary operation, and it's
so easy to get zero in a variable accidentally. That one still feels like
an exception, but yes 1/1e-323 vs. 1/1e-324 would them remain a sore spot.
Likewise, a bunch of operations really should be NaN that are exceptions
now.
On Mon, Sep 14, 2020, 5:26 PM Ben Rudiak-Gould <benrud...@gmail.com> wrote:
> On Mon, Sep 14, 2020 at 9:36 AM Stephen J. Turnbull <
> turnbull.stephen...@u.tsukuba.ac.jp> wrote:
>
>> Christopher Barker writes:
>> > IEEE 754 is a very practical standard -- it was well designed, and is
>> > widely used and successful. It is not perfect, and in certain use
>> cases, it
>> > may not be the best choice. But it's a really good idea to keep to that
>> > standard by default.
>>
>
> I feel the same way; I really wish Python was better about following IEEE
> 754.
>
> I agree, but Python doesn't. It raises on some infs (generally
>> speaking, true infinities), and returns inf on others (generally
>> speaking, overflows).
>>
>
> It seems to be very inconsistent. From testing just now:
>
> * math.lgamma(0) raises "ValueError: math domain error"
>
> * math.exp(1000) raises "OverflowError: math range error"
>
> * math.e ** 1000 raises "OverflowError: (34, 'Result too large')"
>
> * (math.e ** 500) * (math.e ** 500) returns inf
>
> * sum([1e308, 1e308]) returns inf
>
> * math.fsum([1e308, 1e308]) raises "OverflowError: intermediate overflow
> in fsum"
>
> * math.fsum([1e308, inf, 1e308]) returns inf
>
> * math.fsum([inf, 1e308, 1e308]) raises "OverflowError: intermediate
> overflow in fsum"
>
> * float('1e999') returns inf
>
> * float.fromhex('1p1024') raises "OverflowError: hexadecimal value too
> large to represent as a float"
>
> I get the impression that little planning has gone into this. There's no
> consistency in the OverflowError messages. 1./0. raises ZeroDivisionError
> which isn't a subclass of OverflowError. lgamma(0) raises a ValueError,
> which isn't even a subclass of ArithmeticError. The function has a pole at
> 0 with a well-defined two-sided limit of +inf. If it isn't going to return
> +inf then it ought to raise ZeroDivisionError, which should obviously be a
> subclass of OverflowError.
>
> Because of the inconsistent handling of overflow, many functions aren't
> even monotonic. exp(2*x) returns a float for x <= 709.782712893384, raises
> OverflowError for 709.782712893384 < x <= 8.98846567431158e+307, and
> returns a float for x > 8.98846567431158e+307.
>
> 1./0. is not a true infinity. It's the reciprocal of a number that may
> have underflowed to zero. It's totally inconsistent to return inf for
> 1/1e-323 and raise an exception for 1/1e-324, as Python does.
>
> _______________________________________________
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/TXEZTNVIKJFEGPH535KYZ4B5KVNNGBZZ/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/GLUX5WVRF3VBJTD3EBH5MCSRWBASJZOZ/
Code of Conduct: http://python.org/psf/codeofconduct/
