SymPy ComplexInfinity, 1/0 < 2/0, *tests* for symbolic results
FWIW, SymPy (a CAS: Computer Algebra System) has Infinity, NegativeInfinity, ComplexInfinity.
Regarding a symbolic result for 1/0:
If 1/0 is infinity (because 0 goes into 1 infinity times), is 2/0 2*inifnity (because 0 goes into 2 2 times more than into 1)
A proper CAS really is advisable. FWIU, different CAS have different outputs for the above problem (most just disregard the scalar because it's infinity so who care if that cancels out later).
Where are the existing test cases for arithemetic calculations with (scalar times) IEEE-754 int, +inf, or -inf as the output?
On Tue, Sep 15, 2020 at 1:54 AM David Mertz firstname.lastname@example.org wrote:
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 email@example.com wrote:
On Mon, Sep 14, 2020 at 9:36 AM Stephen J. Turnbull < firstname.lastname@example.org> 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
may not be the best choice. But it's a really good idea to keep to
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
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 -- email@example.com To unsubscribe send an email to firstname.lastname@example.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://email@example.com/message/TXEZTN... Code of Conduct: http://python.org/psf/codeofconduct/
Python-ideas mailing list -- firstname.lastname@example.org To unsubscribe send an email to email@example.com https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://firstname.lastname@example.org/message/GLUX5W... Code of Conduct: http://python.org/psf/codeofconduct/