<div dir="ltr">Yeah, I agree, +0. It won't confuse anyone who doesn't care about it and those who need it will benefit.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Sep 20, 2017 at 6:13 PM, Nick Coghlan <span dir="ltr"><<a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 21 September 2017 at 10:44, Chris Barker - NOAA Federal<br>
<<a href="mailto:chris.barker@noaa.gov">chris.barker@noaa.gov</a>> wrote:<br>
[Thibault]<br>
<span class="">>> To sum up:<br>
>> -  In some specific context, hexadecimal floating-point constants make it easy for the programmers to reproduce the exact value. Typically, a software engineer who is concerned about floating-point accuracy would prepare hexadecimal floating-point constants for use in a program by generating them with special software (e.g., Maple, Mathematica, Sage or some multi-precision library). These hexadecimal literals have been added to C (since C99), Java, Lua, Ruby, Perl (since v5.22), etc. for the same reasons.<br>
>> - The exact grammar has been fully documented in the IEEE-754-2008 norm (section 5.12.13), and also in C99 (or C++17 and others)<br>
>> - Of course, hexadecimal floating-point can be manipulated with float.hex() and float.fromhex(), *but* it works from strings, and the translation is done at execution-time...<br>
><br>
> Right. But it addresses all of the points you make. The functionality<br>
> is there. Making a new literal will buy a slight improvement in<br>
> writability and performance.<br>
><br>
> Is that worth much in a dynamic language like python?<br>
<br>
</span>I think so, as consider this question: how do you write a script that<br>
accepts a user-supplied string (e.g. from a CSV file) and treats it as<br>
hex floating point if it has the 0x prefix, and decimal floating point<br>
otherwise?<br>
<br>
You can't just blindly apply float.fromhex(), as that will also treat<br>
unprefixed strings as hexadecimal:<br>
<br>
>>> float.fromhex("0x10")<br>
16.0<br>
>>> float.fromhex("10")<br>
16.0<br>
<br>
So you need to do the try/except dance with ValueError instead:<br>
<br>
    try:<br>
        float_data = float(text)<br>
    except ValueError:<br>
        float_values = float.fromhex(text)<br>
<br>
At which point you may wonder why you can't just write "float_data =<br>
float(text, base=0)" the way you can for integers:<br>
<br>
>>> int("10", base=0)<br>
10<br>
>>> int("0x10", base=0)<br>
16<br>
<br>
And if the float() builtin were to gain a "base" parameter, then it's<br>
only a short step from there to allow at least the "0x" prefix on<br>
literals, and potentially even "0b" and "0o" as well.<br>
<br>
So I'm personally +0 on the idea - it would improve interface<br>
consistency between integers and floating point values, and make it<br>
easier to write correctness tests for IEEE754 floating point hardware<br>
and algorithms in Python (where your input & output test vectors are<br>
going to use binary or hex representations, not decimal).<br>
<br>
Cheers,<br>
Nick.<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Nick Coghlan   |   <a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>   |   Brisbane, Australia<br>
</font></span><div class="HOEnZb"><div class="h5">______________________________<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>
</div></div></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">--Guido van Rossum (<a href="http://python.org/~guido" target="_blank">python.org/~guido</a>)</div>
</div>