Eli Stevens <[email protected]> added the comment:
I see the distinction about the rounding error now. Thanks for clarifying;
I've added more tests as suggested.
Looking at _struct.c, line 2085:
/* Skip float and double, could be
"unknown" float format */
if (ptr->format == 'd' || ptr->format == 'f')
break;
ptr->pack = native->pack;
ptr->unpack = native->unpack;
break;
I'm going to assume that it's okay to allow 'e' to pass through here, since the
'e' type is *always* going to be in IEEE 754 (not "unknown") floating point
format, and the handling routines don't rely on the C conversions the way the
float/double ones do. Is that a good assumption to make?
Also, looking at the line in the native_table declaration:
{'e', sizeof(short), SHORT_ALIGN, nu_halffloat, np_halffloat},
Does it make sense to have an entry here since there isn't actually a native
representation? ATM it's implemented as just figuring out the platform
endianness, and then calling the corresponding lp_/lu_ or bp_/bu_ function.
----------
_______________________________________
Python tracker <[email protected]>
<http://bugs.python.org/issue11734>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
