Of course, for a lost of numbers, the decimal representation is simpler, and just as accurate as the radix-2 hexadecimal representation. But, due to the radix-10 and radix-2 used in the two representations, the radix-2 may be much easier to use.
Hex is radix 16, not radix 2 (binary). Of course, Hex is radix-16! I was talking about radix-2 because all the exactness problem comes when converting binary and decimal, and Hex can be seen as an (exact) compact way to express binary, and that's what we want (build literal floats in the same exact way they are stored internally, and export them exactly in a compact way).
In the "Handbook of Floating-Point Arithmetic" (JM Muller et al, Birkhauser editor, page 40),the authors claims that the largest exact decimal representation of a double-precision floating-point requires 767 digits !! So it is not always few characters to type to be just as accurate !! For example (this is the largest exact decimal representation of a single-precision 32-bit float):
1.17549421069244107548702944484928734882705242874589333385717453057158887047561890426550235133618116378784179687e-38 and 0x1.fffffc0000000p-127 are exactly the same number (one in decimal representation, the other in radix-2 hexadecimal)!
That may be so, but that doesn't mean you have to type all 100+ digits in order to reproduce the float exactly. Just 1.1754942106924411e-38 is sufficient:
py> 1.1754942106924411e-38 == float.fromhex('0x1.fffffc0000000p-127') True
You may be mistaking two different questions:
(1) How many decimal digits are needed to exactly convert the float to decimal? That can be over 100 for a C single, and over 700 for a double.
(2) How many decimal digits are needed to uniquely represent the float? Nine digits (plus an exponent) is enough to represent all possible C singles; 17 digits is enough to represent all doubles (Python floats).
You're absolutely right, 1.1754942106924411e-38 is enough to reproduce the float exactly, BUT it is still different to 0x1.fffffc0000000p-127 (or it's 112-digits decimal representation). Because 1.1754942106924411e-38 is rounded at compile-time to 0x1.fffffc0000000p-127 (so exactly to 1.17549421069244107548702944484928734882705242874589333385717453057158887047561890426550235133618116378784179687e-38 in decimal).
So 17 digits are enough to reach each double, after the compile-time quantization. But "explicit is better than implicit", as someone says ;-), so I prefer, in some particular occasions, to explicitly express the floating-point number I want (like 0x1.fffffc0000000p-127), rather than hoping the quantization of my decimal number (1.1754942106924411e-38) will produce the right floating-point (0x1.fffffc0000000p-127)
And that's one of the reasons why the hexadecimal floating-point representation exist:
I'm not actually opposed to hex float literals. I think they're cool. But we ought to have a reason more than just "they're cool" for supporting them, and I'm having trouble thinking of any apart from "C supports them, so should we". But maybe that's enough.
To sum up:
I hope this can be seen as a sufficient reason to support hexadecimal floating literals.