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 believ
Hi,
For AIX:
Python 2.2 (#1, Feb 17 2003, 21:43:03) [C] on aix4
Type "help", "copyright", "credits" or "license" for more information.
>>> import marshal
>>> marshal.dumps(1e1)
'f\x03INF'
>>> marshal.loads(marshal.dumps(1e1))
INF
>>> float("INF")
INF
>>> float("NaN")
NaNQ
>>>
On 4/9/0
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 this was the Floating Instruction Se
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 int
...
[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 ab
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
[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 re
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 "", lin
...
[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 half-m
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 peop
[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
>> Pyt
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
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
[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 routine
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 mor
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.
>
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:
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")
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 every
Terry Reedy wrote:
> The particular issue here is not platform dependence as such but
> within-platform usage dependence, as in the same code giving radically
> different answers in a standard interactive console window and an idle
> window, or when you run it the first time (from xx.py) versus
20 matches
Mail list logo
