On Thu, Jun 26, 2008 at 9:30 PM, "Martin v. Löwis" <[EMAIL PROTECTED]>
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
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
