<div dir="auto">I think you are missing the point I was assuming at. Having a binary/hex float literal would tempt users to think "I know EXACTLY what number I'm spelling this way"... where most users definitely don't in edge cases.<div dir="auto"><br></div><div dir="auto">Spelling it float.fromhex(s) makes it more obvious "this is an expert operation I may not understand the intricacies of."</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sep 21, 2017 6:32 PM, "Steven D'Aprano" <<a href="mailto:steve@pearwood.info">steve@pearwood.info</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Thu, Sep 21, 2017 at 01:09:11PM -0700, David Mertz wrote:<br>
> -1<br>
><br>
> Writing a floating point literal requires A LOT more knowledge than writing<br>
> a hex integer.<br>
><br>
> What is the bit length of floats on your specific Python compile?<br>
<br>
Are there actually any Python implementations or builds which have<br>
floats not equal to 64 bits? If not, perhaps it is time to make 64 bit<br>
floats a language guarantee.<br>
<br>
<br>
> What<br>
> happens if you specify more or less precision than actually available.<br>
<br>
I expect the answer will be "exactly the same as what already<br>
happens right now". Why wouldn't it be?<br>
<br>
py> float.fromhex('0x1.<wbr>81cd5c28f5c290000000089p+13')<br>
12345.67<br>
py> float('12345.6700000000000089'<wbr>)<br>
12345.67<br>
<br>
<br>
> Where is the underflow to subnormal numbers?<br>
<br>
Same place it is right now.<br>
<br>
<br>
> What is the bit representation<br>
> of information? Nan? -0 vs +0?<br>
<br>
Same as it is now.<br>
<br>
<br>
> There are people who know this and need to know this. But float.fromhex()<br>
> is already available to them. A literal is an attractive nuisance for<br>
> people who almost-but-not-quite understand IEEE-854. I.e. those people who<br>
> named neither Tim Peters nor Mike Cowlishaw.<br>
<br>
Using a different sized float is going to affect any representation of<br>
floats, whether it is in decimal or in hex. If your objections are valid<br>
for hex literals, then they're equally valid (if not more so!) for<br>
decimal literals, and we're left with the conclusion that nobody except<br>
Tim Peters and Mike Cowlishaw can enter floats into source code, or<br>
convert them from strings.<br>
<br>
And I think that's silly. Obviously many people can and do successfully<br>
use floats all the time, without worrying whether or not the code is<br>
absolutely, 100% consistent across all platforms, including that weird<br>
build on Acme YouNicks with 57 bit floats.<br>
<br>
People who care about weird builds can use sys.float_info to find out<br>
what they need to know, and adjust accordingly. Those who don't will<br>
continue to do what they're already doing: assume floats are 64-bit C<br>
doubles, and live in a state of blissful ignorance about alternatives<br>
until somebody reports a bug, which they'll close as "won't fix".<br>
<br>
<br>
--<br>
Steve<br>
______________________________<wbr>_________________<br>
Python-ideas mailing list<br>
<a href="mailto:Python-ideas@python.org">Python-ideas@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-ideas" rel="noreferrer" target="_blank">https://mail.python.org/<wbr>mailman/listinfo/python-ideas</a><br>
Code of Conduct: <a href="http://python.org/psf/codeofconduct/" rel="noreferrer" target="_blank">http://python.org/psf/<wbr>codeofconduct/</a><br>
</blockquote></div></div>