bltinmodule.c (original) (raw)

Mark Dickinson dickinsm at gmail.com
Thu Jun 26 22:46:05 CEST 2008

On Thu, Jun 26, 2008 at 9:30 PM, "Martin v. Löwis" <martin at v.loewis.de> wrote:

> Answering for myself: because it gives an exact representation of a > floating-point number in a fairly human-readable format.

Ok. But py> binascii.hexlify(struct.pack("d", 3.14)) '1f85eb51b81e0940' does that already, no? You won't know the precise value, but you won't know that with hex support, either.

The output from hex_float(3.14) would be something like:

'0x1.91eb851eb851fp+1'

The exponent is still usually given in decimal; there's no need for it to be hexadecimal for exactness.

I'd question that the user is able to make sense of a number when

mantissa and exponent is represented in hex.

I think the above it still a bit easier to understand than if one has to figure out where the sign/exponent and exponent/fraction bit boundaries are, unbias the exponent, and add the extra hidden '1' bit into the mantissa. That's a lot of mental work.

Then I'd argue that the feature should be symmetric: If there is support for printing floating point numbers as hex, there should also be support for hex floating point literals.

I agree with this. Or at least support for hex floating point strings, if not literals.

Also, to follow C's tradition, it would be better if that was not integrated into the hex function (or a hex method), but if there was support for %a in string formatting.

I'd be delighted with '%a' support.

Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20080626/ef2c536a/attachment.htm>

More information about the Python-Dev mailing list