[ python-Bugs-1080440 ] float issue for NaN type in .pyc file

Sun Dec 19 17:35:44 CET 2004

Bugs item #1080440, was opened at 2004年12月07日 06:24
Message generated for change (Comment added) made by mwh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080440&group_id=5470
Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Dileep Nirala (dileep_nirala)
Assigned to: Nobody/Anonymous (nobody)
Summary: float issue for NaN type in .pyc file
Initial Comment:
There is a difference in output between .pyc and .py 
file, while dealing with NaN float. In fact I am doing 
a float range validation as part of my requirement. 
The content of my sample program
[test.py]
aboveMax = 1.8e+308
belowMin = -1.8e+308
print aboveMax, belowMin
While execution:
command: python test.py
output: 1.#INF -1.#INF
This output is expected and good, however if I use 
compiled python file as below,
command: python test.pyc
output: 1.0 -1.0 
This output is wrong, it does not show Nan floating 
point. 
----------------------------------------------------------------------
>Comment By: Michael Hudson (mwh)
Date: 2004年12月19日 16:35
Message:
Logged In: YES 
user_id=6656
And, er, how do you do that?
AFAIK, isnan is in SUS and C99 and recommended by IEEE-754 but isn't 
in plain old ANSI C... I also suspect that it's supported by all platforms 
we care about that, but certainly wouldn't swear to it.
OTOH, pyport.h seems to have a Py_IS_NAN macro already. Maybe that 
would work, at least enough of the time to be useful...
----------------------------------------------------------------------
Comment By: Jeff Epler (jepler)
Date: 2004年12月19日 03:10
Message:
Logged In: YES 
user_id=2772
If this is all accidental behavior, maybe something
(marshal? the compiler?) could issue a warning when a
special value is parsed, or marshal.dump()'d.
Imagining something like:
>>> 2e308
<stdin>:1: OverflowWarning: behavior of special
floating-point value undefined.
inf
Or else:
>>> marshal.dumps(2e308)
<stdin>:1: RuntimeWarning: marshal of special floating-point
value undefined.
's\x05\x00\x00\x002e308'
----------------------------------------------------------------------
Comment By: Tim Peters (tim_one)
Date: 2004年12月07日 17:33
Message:
Logged In: YES 
user_id=31435
BTW, while nothing is guaranteed here, your best shot 
at working (albeit still by accident) portable code is to 
use expressions that don't tickle IEEE special values 
directly. For example, use
pinf = 1e300 * 1e300
minf = -pinf
nan = pinf - pinf
That will work the same way from .py or .pyc. Whether 
pinf is actually +Infinity and nan is actually a NaN then 
remain platform-dependent accidents, but they will be 
on the majority platforms (Linux and Windows, using gcc 
or MSVC to compile Python).
----------------------------------------------------------------------
Comment By: Tim Peters (tim_one)
Date: 2004年12月07日 17:13
Message:
Logged In: YES 
user_id=31435
dileep_nirala: Yes, I understood the problem. That 
your test passed the first time was an accident. That 
your test failed the second time was also an accident. 
Nothing is defined about what happens in Python in the 
presence of NaNs. The most likely accident is that no 
spelling of an infinity, NaN, or negative 0.0 will survive 
when loaded from a .pyc file. That the 
literal "1.8e+308" gave you an infinity to begin with was 
also a platform-dependent accident. Python has no 
support for these things. Whatever support may 
*appear* to exist derives from more-or-less random 
behaviors dervied from the platform C compiler and 
runtime libraries. That won't be fixed unless someone 
unexpectedly volunteers a lot of new work in this area.
----------------------------------------------------------------------
Comment By: Michael Hudson (mwh)
Date: 2004年12月07日 14:51
Message:
Logged In: YES 
user_id=6656
I know first hand how much of a pain this issue can be.
However it's not clear what can be done about it. My vote
would go towards complaining at compile time that the
literals cannot be represented as a regular double, but even
that isn't the easiest thing to do portably!
----------------------------------------------------------------------
Comment By: Dileep Nirala (dileep_nirala)
Date: 2004年12月07日 13:54
Message:
Logged In: YES 
user_id=1173293
My test cases passes for the first time but fails second 
times onward since .pyc gets loaded since it's existing.
----------------------------------------------------------------------
Comment By: Tim Peters (tim_one)
Date: 2004年12月07日 07:51
Message:
Logged In: YES 
user_id=31435
Python guarantees nothing about behavior in the 
presence of NaNs, infinities, or signed zeroes. Anything 
you see then is a platform-dependent accident.
This should be closed with a reference to PEP 42 (I don't 
have time to look it all up now -- "non-accidental" IEEE 
behavior is a longstanding feature request, but one 
unlikely to be resolved in the foreseeable future; the 
particular problem here is that the marshal format deals 
in accidental ways with infinities, NaNs, and signed 
zeroes, so accidents in .py files may not be reproduced 
from .pyc files)
----------------------------------------------------------------------
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080440&group_id=5470