P
Peter Hansen
I'm investigating a puzzling problem involving an attempt to generate a
constant containing an (IEEE 754) "infinity" value. (I understand that
special float values are a "platform-dependent accident" etc...)
The issue appears possibly to point to a bug in the Python compiler,
with it producing inconsistent results. I'm using "Python 2.4.2 (#67,
Sep 28 2005, 12:41:11) [MSC v.1310 32 bit (Intel)] on win32".
This code sometimes produces a float of 1.0, sometimes infinity (or,
since I'm on Windows, the float with string representation of "1.#INF"),
as seen in the operand of the LOAD_CONST instruction:
def floatstr(o, allow_nan=True):
INFINITY = 1e66666
# more code follows which does *not* rebind INFINITY
27 0 LOAD_CONST 1 (1.0)
3 STORE_FAST 2 (INFINITY)
....
And, at other times, under circumstances I've yet to isolate:
27 0 LOAD_CONST 1 (1.#INF)
3 STORE_FAST 2 (INFINITY)
...
I'll keep digging to narrow down what's going on, but I wondered if
anyone had heard of or seen a similar problem, or is aware of an
existing issue that could cause this. I checked the list on sourceforge
but can't see anything relevant, nor did Google help.
Just had a thought: could this be an issue involving "marshal" and
either the writing of or reading of the .pyc file? Is it known to be
unsafe to have Python source with special float constants?
-Peter
constant containing an (IEEE 754) "infinity" value. (I understand that
special float values are a "platform-dependent accident" etc...)
The issue appears possibly to point to a bug in the Python compiler,
with it producing inconsistent results. I'm using "Python 2.4.2 (#67,
Sep 28 2005, 12:41:11) [MSC v.1310 32 bit (Intel)] on win32".
This code sometimes produces a float of 1.0, sometimes infinity (or,
since I'm on Windows, the float with string representation of "1.#INF"),
as seen in the operand of the LOAD_CONST instruction:
def floatstr(o, allow_nan=True):
INFINITY = 1e66666
# more code follows which does *not* rebind INFINITY
27 0 LOAD_CONST 1 (1.0)
3 STORE_FAST 2 (INFINITY)
....
And, at other times, under circumstances I've yet to isolate:
27 0 LOAD_CONST 1 (1.#INF)
3 STORE_FAST 2 (INFINITY)
...
I'll keep digging to narrow down what's going on, but I wondered if
anyone had heard of or seen a similar problem, or is aware of an
existing issue that could cause this. I checked the list on sourceforge
but can't see anything relevant, nor did Google help.
Just had a thought: could this be an issue involving "marshal" and
either the writing of or reading of the .pyc file? Is it known to be
unsafe to have Python source with special float constants?
-Peter