This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author Eli.Stevens
Recipients Eli.Stevens, mark.dickinson, mark.wiebe
Date 2011-04-05.06:53:48
SpamBayes Score 2.4650448e-11
Marked as misclassified No
Message-id <1301986429.17.0.414601790109.issue11734@psf.upfronthosting.co.za>
In-reply-to
Content
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.
History
Date User Action Args
2011-04-05 06:53:49Eli.Stevenssetrecipients: + Eli.Stevens, mark.dickinson, mark.wiebe
2011-04-05 06:53:49Eli.Stevenssetmessageid: <1301986429.17.0.414601790109.issue11734@psf.upfronthosting.co.za>
2011-04-05 06:53:48Eli.Stevenslinkissue11734 messages
2011-04-05 06:53:48Eli.Stevenscreate