bltinmodule.c (original) (raw)

"Martin v. Löwis" martin at v.loewis.de
Thu Jun 26 23:35:44 CEST 2008

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.

Sure. However, I'd argue that most people are unable to even remotely guess the number in decimal when presented with the number in hexadecimal - at a minimum, they'll fail to recognize that the exponent is not to the power of 10, or when they realize that, might guess that it is to the power of 16 (I find it fairly confusing, but consequential, that it is to the power of 2, even when the digits are hex - and then, the exponent is decimal :-).

So I'd like to dismiss any objective of "the output must be human-understandable" as unrealistic. That an unambiguous representation is desired, I can understand - but only if there also is a way to enter the same representation elsewhere.

In addition, I fail to see the point in binary representation. For unambiguous representation, it's sufficient to use hex. I can't accept claims that people will be actually able to understand what number is represented when given the bit string. For educational purposes, decoding mantissa and biased exponent directly out of the IEEE representation is better than having binary output builtin.

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.

I personally find that much less problematic than extending the hex, and wouldn't object to a patch providing such formatting (assuming it does the same thing that C99 printf does).

Regards, Martin

More information about the Python-Dev mailing list