Message60255
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? |
|
Date |
User |
Action |
Args |
2008-01-20 01:51:26 | mark.dickinson | set | spambayes_score: 0.00393321 -> 0.0039332095 recipients:
+ mark.dickinson, tim.peters, collinwinter, facundobatista, richardh2003, christian.heimes |
2008-01-20 01:51:26 | mark.dickinson | set | spambayes_score: 0.00393321 -> 0.00393321 messageid: <1200793886.43.0.206087211754.issue705836@psf.upfronthosting.co.za> |
2008-01-20 01:51:25 | mark.dickinson | link | issue705836 messages |
2008-01-20 01:51:24 | mark.dickinson | create | |
|