>
> I think the feature is misguided in the first place. Why do you want
> a hex representation of floating point numbers?
>
>
> 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.
> struct.pack would only show the bit layout, leaving the user to
> manually extract the sign bit, exponent, and fraction, and then make
> sense of the whole thing.
I'd question that the user is able to make sense of a number when
mantissa and exponent is represented in hex.
> I'd say that bin and hex are special: bin is natural because
> floats are usually thought of, and stored as, binary numbers.
> hex is special because it gives a compact way of representing
> a float, and because there's already a history of using hex
> floats in numerical analysis literature and in programming
> languages (C99, Java, ...)
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.
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.
Regards,
Martin
_______________________________________________
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
