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
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
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.