[Python-bugs-list] [ python-Bugs-705836 ] struct.pack of floats in non-native endian order
SourceForge.net
noreply@sourceforge.net
Wed, 19 Mar 2003 21:26:00 -0800
Bugs item #705836, was opened at 2003-03-18 15:17
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=705836&group_id=5470
Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
>Priority: 7
Submitted By: Richard Hill (richardh2003)
Assigned to: Tim Peters (tim_one)
Summary: struct.pack of floats in non-native endian order
Initial Comment:
Python version 2.1 (2.2.1 behaves the same).
Windows 2000 and RH Linux 8.0
This was run on an Intel platform.
>>> v = 7.0 + .1 + .1 + .1 + .1 + .1 + .1 + .1 + .1 + .1
+ .1
>>> v
7.9999999999999964
>>> struct.pack( "f", v )
'\x00\x00\x00A'
>>> struct.pack( ">f", v )
'@\x80\x00\x00'
These two should be the same byte pattern (only
reversed)!
>>> struct.unpack( ">f", '@\x80\x00\x00' )
(4.0,)
!!!!!
----------------------------------------------------------------------
>Comment By: Tim Peters (tim_one)
Date: 2003-03-20 00:25
Message:
Logged In: YES
user_id=31435
Boosted priority because this is an especially bad kind of
bug: mysterious, subtle, and very rare ("most" in-range
floats pack under "<f" and ">f" without problems; a problem
requires that a carry out of the 25th most-significant-bit
propagate thru a solid string of 24 1 bits).
For 2.2 I expect to check in a quick hack. In 2.3 this code
needs refactoring (structmodule and cPickle shouldn't have
duplicated this delicate code)
----------------------------------------------------------------------
Comment By: Tim Peters (tim_one)
Date: 2003-03-19 14:01
Message:
Logged In: YES
user_id=31435
Yuck. It's a bug in not accounting for that rounding can
spill over the original bit width. structmodule's pack_float()
and pack_double() both have this flaw, although the one in
pack_double() is much subtler. A similar cut-and-paste
bug is in cPicke's save_float(). I'll fix all this.
Note: while "<f"'s result should be the byte-reversal
of ">f"'s, there's no defined relationship between either of
those and plain "f". "f" is platform-native in all respects. "<f"
and ">f" force an IEEE-like encoding, even on non-IEEE
platforms.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=705836&group_id=5470