Mark Dickinson added the comment: It's a little odd: the relevant code is in floatobject.c, in _PyFloat_Pack4. The issue is what happens when a Python float (stored internally as a platform double) is packed as an IEEE-754 single-precision float. The current code doesn't behave consistently across platforms:
- if the platform float format is unknown, the code turns a Python float into an IEEE-754 float anyway, and goes to great lengths to raise OverflowError when the Python float is too large to fit into an IEEE single-precision float. - if the platform float format is recognised as IEEE-754, then a C cast is used to turn the Python float (stored as a double) into a single-precision float; for something that's too large for single precision, the natural result of that conversion is an IEEE-754 infinity. I'm not 100% sure that the C standard (even C99) actually guarantees this, or whether there's a danger of floating-point exceptions being raised here. I think the behaviour should be consistent: either always raise OverflowError or always return the 4-byte sequence corresponding to an infinity. I'm not sure which. From the test-suite, it's clear that the original intention was that OverflowError should be raised. On the other hand, 98.22% of Python users (i.e. those on IEEE-754 platforms) have been living happily with the 'output an infinity' behaviour for the last 5 years without noticing. And we've been moving towards exposing infinities and NaNs more within Python. One the OverflowError/infinity decision is made, this is a relatively easy fix, and I'd be happy to take care of it. Christian, do you have any thoughts on this issue? ---------- nosy: +marketdickinson, tiran ____________________________________ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue705836> ____________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
