Author mark.wiebe
Recipients Eli.Stevens, mark.dickinson, mark.wiebe
Date 2011-04-04.19:12:32
SpamBayes Score 3.88395e-10
Marked as misclassified No
Message-id <1301944353.62.0.726753795968.issue11734@psf.upfronthosting.co.za>
In-reply-to
Content
The patch currently assumes IEEE 754 with byte-order matching the integer type. I see that pyconfig.h defines three possible cases when IEEE 754 doubles are supported, DOUBLE_IS_LITTLE_ENDIAN_IEEE754, DOUBLE_IS_BIG_ENDIAN_IEEE754, and DOUBLE_IS_ARM_MIXED_ENDIAN_IEEE754. The code should have some byte swapping to match it to the integer endianness.

If support for non-IEEE systems is still desired, implementing a conversion using isnan/isinf/frexp/ldexp should be pretty easy, though off hand I can't see an efficient way to extract the significand bits.

Regarding the PY_LONG_LONG, it should have been unsigned PY_LONG_LONG. Using PY_UINT64_T is better, though, since a bigger PY_LONG_LONG would cause trouble in the union.

For the UINT32, maybe just using the double/PY_UINT64_T versions is better, since there is no macro for FLOAT_IS_IEEE754? Falling back to a frexpr implementation if double isn't IEEE or there is no 64-bit integer type may be a reasonable tradeoff to support the few platforms where that's the case, and 2 instead of 3 separate conversion codes is a bit better maintenance-wise.
History
Date User Action Args
2011-04-04 19:12:33mark.wiebesetrecipients: + mark.wiebe, mark.dickinson, Eli.Stevens
2011-04-04 19:12:33mark.wiebesetmessageid: <1301944353.62.0.726753795968.issue11734@psf.upfronthosting.co.za>
2011-04-04 19:12:32mark.wiebelinkissue11734 messages
2011-04-04 19:12:32mark.wiebecreate