Bugs item #705836, was opened at 2003-03-18 15:17 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=705836&group_id=5470
Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: None >Status: Open Resolution: Fixed Priority: 7 Private: No 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: Collin Winter (collinwinter) Date: 2007-03-29 18:38 Message: Logged In: YES user_id=1344176 Originator: NO Reopening. The test case committed in r31892 is broken, specifically the part that checks for an OverflowError towards the end: the TestFailed exception is only instanced, never raised. Actually raising the TestFailed instance causes the test to fail. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-03-20 13:48 Message: Logged In: YES user_id=31435 Fixed. In the 2.2 branch: Lib/test/test_struct.py; new revision: 1.14.12.1 Misc/NEWS; new revision: 1.337.2.4.2.68 Modules/cPickle.c; new revision: 2.73.2.1.2.4 Modules/structmodule.c; new revision: 2.51.8.2 For 2.3: Lib/test/test_struct.py; new revision: 1.17 Misc/NEWS; new revision: 1.700 Modules/cPickle.c; new revision: 2.141 Modules/structmodule.c; new revision: 2.58 ---------------------------------------------------------------------- Comment By: Richard Hill (richardh2003) Date: 2003-03-20 07:33 Message: Logged In: YES user_id=737060 Thanks for getting back to me. Your comment regarding IEEE formats is very interesting, I didn't know about this behaviour. ---------------------------------------------------------------------- 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 _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
