On 14-apr-05, at 15:08, David Robinow wrote:
On 4/11/05, Tim Peters [EMAIL PROTECTED] wrote:
Heh. I have a vague half-memory of _some_ box that stored the two
4-byte words in an IEEE double in one order, but the bytes within
each word in the opposite order. It's always something ...
I believe
My mail is experincing random delays of up to a few hours at the
moment. I wrote this before I saw your comments on my patch.
Tim Peters [EMAIL PROTECTED] writes:
[Michael Hudson]
I've just submitted http://python.org/sf/1180995 which adds format
codes for binary marshalling of floats if
...
[mwh]
I recall stories of machines that stored the bytes of long in some
crazy order like that. I think Python would already be broken on such
a system, but, also, don't care.
[Tim]
Python does very little that depends on internal native byte order,
and C hides it in the absence of
Tim Peters [EMAIL PROTECTED] writes:
...
[mwh]
I recall stories of machines that stored the bytes of long in some
crazy order like that. I think Python would already be broken on such
a system, but, also, don't care.
[Tim]
Python does very little that depends on internal native byte
Tim Peters [EMAIL PROTECTED] writes:
The 754 standard doesn't say anything about how the difference between
signaling and quiet NaNs is represented. So it's possible that a qNaN
on one box would look like an sNaN on a different box, and vice
versa. But since most people run with all FPU
[Tim]
The 754 standard doesn't say anything about how the difference between
signaling and quiet NaNs is represented. So it's possible that a qNaN
on one box would look like an sNaN on a different box, and vice
versa. But since most people run with all FPU traps disabled, and
Python doesn't
Tim Peters [EMAIL PROTECTED] writes:
[Tim]
The 754 standard doesn't say anything about how the difference between
signaling and quiet NaNs is represented. So it's possible that a qNaN
on one box would look like an sNaN on a different box, and vice
versa. But since most people run with all
...
[mwh]
OK, so the worst that could happen here is that moving marshal data
from one box to another could turn one sort of NaN into another?
Right. Assuming source and destination boxes both use 754 format, and
the implementation adjusts endianess if necessary.
Heh. I have a vague
I've just submitted http://python.org/sf/1180995 which adds format
codes for binary marshalling of floats if version 1, but it doesn't
quite have the effect I expected (see below):
inf = 1e308*1e308
nan = inf/inf
marshal.dumps(nan, 2)
Traceback (most recent call last):
File stdin, line 1,
[Michael Hudson]
I've just submitted http://python.org/sf/1180995 which adds format
codes for binary marshalling of floats if version 1, but it doesn't
quite have the effect I expected (see below):
inf = 1e308*1e308
nan = inf/inf
marshal.dumps(nan, 2)
Traceback (most recent call last):
Fredrik Lundh wrote:
pickle doesn't have the INF=1.0 bug:
import pickle
pickle.loads(pickle.dumps(1e1))
...
ValueError: invalid literal for float(): 1.#INF
import cPickle
cPickle.loads(cPickle.dumps(1e1))
...
ValueError: could not convert string to float
import marshal
Scott David Daniels wrote:
From yesterday's sprint
sprint? I was beginning to wonder why nobody cared about this;
guess I missed the announcement ;-)
At the least a change like this will catch the unpacking:
in marshal.c (around line 500) in function r_object:
PyFPE_START_PROTECT(atof,
marshal shouldn't be representing doubles as decimal strings to begin
with. All code for (de)serialing C doubles should go thru
_PyFloat_Pack8() and _PyFloat_Unpack8(). cPickle (proto = 1) and
struct (std mode) already do; marshal is the oddball.
But as the docs (floatobject.h) for these say:
Tim Peters [EMAIL PROTECTED] writes:
marshal shouldn't be representing doubles as decimal strings to begin
with. All code for (de)serialing C doubles should go thru
_PyFloat_Pack8() and _PyFloat_Unpack8(). cPickle (proto = 1) and
struct (std mode) already do; marshal is the oddball.
But
Michael I suppose one could jsut do it unconditionally and wait for one
Michael of the three remaining VAX users[2] to compile Python 2.5 and
Michael then notice.
You forgot the two remaining CRAY users. Since their machines are so much
more powerful than VAXen, they have much more
[mwh]
OTOH, the implementation has this comment:
/*
* _PyFloat_{Pack,Unpack}{4,8}. See floatobject.h.
*
* TODO: On platforms that use the standard IEEE-754 single and double
* formats natively, these routines
On Apr 10, 2005, at 13:44, Skip Montanaro wrote:
Michael I suppose one could jsut do it unconditionally and wait
for one
Michael of the three remaining VAX users[2] to compile Python 2.5
and
Michael then notice.
You forgot the two remaining CRAY users. Since their machines are so
Fredrik Lundh wrote:
[...]
and yes, someone should fix the NaN mess, but I guess everyone's too
busy removing unworthy developers from sourceforge to bother working
on stuff that's actually useful for real Python users...
That's not at all true. Some of us are busy giving up commit privileges
in
Martin Yet, this *still* is a platform dependence. Python makes no
Martin guarantee that 1e1000 is a supported float literal on any
Martin platform, and indeed, on your platform, 1e1000 is not supported
Martin on your platform.
Are float(inf) and float(nan) supported everywhere?
Skip Montanaro wrote:
Martin Yet, this *still* is a platform dependence. Python makes no
Martin guarantee that 1e1000 is a supported float literal on any
Martin platform, and indeed, on your platform, 1e1000 is not supported
Martin on your platform.
Are float(inf) and
Scott David Daniels wrote:
What should marshal / unmarshal do with floating point NaNs (the case we
are worrying about is Infinity) ? The current behavior is not perfect.
Michael Spencer chased down a supposed Idle problem to (on Win2k):
marshal.dumps(1e1) == 'f\x061.#INF'
21 matches
Mail list logo
