[Python-ideas] Hexadecimal floating literals

[Tim Peters]

[David Mertz <mertz at gnosis.cx>]
> -1
>
> Writing a floating point literal requires A LOT more knowledge than writing
> a hex integer.

But not really more than writing a decimal float literal in
"scientific notation".  People who use floats are used to the latter.
Besides using "p" instead of "e" to mark the exponent, the only
differences are that the mantissa is expressed in hex instead of in
decimal, and the implicit base to which the exponent is applied is 2
instead of 10.

Either way it's a notation for a rational number, which may or may not
be exactly representable in the native HW float format.


> What is the bit length of floats on your specific Python compile? What
> happens if you specify more or less precision than actually available.
> Where is the underflow to subnormal numbers?

All the same answers apply as when using decimal "scientific
notation".  When the denoted rational isn't exactly representable,
then a maze of rounding, overflow, and/or underflow rules apply.  The
base the literal is expressed in doesn't really have anything to do
with those.


> What is the bit representation of [infinity]? Nan?

Hex float literals in general have no way to spell those:  it's just a
way to spell a subset of (mathematical) rational numbers.  Python,
however, does support special cases for those:

>>> float.fromhex("inf")
inf
>>> float.fromhex("nan")
nan


> -0 vs +0?

The obvious first attempts work fine for those ;-)


> There are people who know this and need to know this. But float.fromhex() is
> already available to them. A literal is an attractive nuisance for people
> who almost-but-not-quite understand IEEE-854.

As notations for rationals, nobody needs to understand 854 at all to
use these things, so long as they stick to exactly representable
numbers.  Whether a specific literal _is_ exactly representable, and
what happens if it's not, does require understanding a whole lot - but
that's also true of decimal float literals.

> I.e. those people who named neither Tim Peters nor Mike Cowlishaw.

Or Mark Dickinson ;-)

All that said, I'm -0 on the idea.  I doubt I (or Mark, or Mike) would
use it, because the need is rare and float.fromhex() is already
sufficient.  Indeed, `fromhex()` is less annoying, because it does
support special cases for infinities and NaNs, and doesn't _require_ a
"0x" prefix.