On Thu, Sep 21, 2017 at 01:09:11PM -0700, David Mertz wrote:
Writing a floating point literal requires A LOT more knowledge than writing a hex integer.
What is the bit length of floats on your specific Python compile?
Are there actually any Python implementations or builds which have floats not equal to 64 bits? If not, perhaps it is time to make 64 bit floats a language guarantee.
What happens if you specify more or less precision than actually available.
I expect the answer will be "exactly the same as what already happens right now". Why wouldn't it be?
py> float.fromhex('0x1.81cd5c28f5c290000000089p+13') 12345.67 py> float('12345.6700000000000089') 12345.67
Where is the underflow to subnormal numbers?
Same place it is right now.
What is the bit representation of information? Nan? -0 vs +0?
Same as it is now.
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. I.e. those people who named neither Tim Peters nor Mike Cowlishaw.
Using a different sized float is going to affect any representation of floats, whether it is in decimal or in hex. If your objections are valid for hex literals, then they're equally valid (if not more so!) for decimal literals, and we're left with the conclusion that nobody except Tim Peters and Mike Cowlishaw can enter floats into source code, or convert them from strings.
And I think that's silly. Obviously many people can and do successfully use floats all the time, without worrying whether or not the code is absolutely, 100% consistent across all platforms, including that weird build on Acme YouNicks with 57 bit floats.
People who care about weird builds can use sys.float_info to find out what they need to know, and adjust accordingly. Those who don't will continue to do what they're already doing: assume floats are 64-bit C doubles, and live in a state of blissful ignorance about alternatives until somebody reports a bug, which they'll close as "won't fix".