[Python-Dev] [Python-checkins] r64424 - in python/trunk:Include/object.h Lib/test/test_sys.py Misc/NEWSObjects/intobject.c Objects/longobject.c Objects/typeobject.cPython/bltinmodule.c

[Mark Dickinson]

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>