<div dir="auto"><div dir="ltr">When I teach, I usually present this to students:<div><br></div><div><div>>>> (0.1 + 0.2) + 0.3 == 0.1 + (0.2 + 0.3)</div><div>False</div></div><div><br></div><div>This is really easy as a way to say "floating point numbers are approximations where you often encounter rounding errors"  The fact the "edge cases" are actually pretty central and commonplace in decimal approximations makes this a very easy lesson to teach.</div><div><br></div><div>After that, I might discuss using deltas, or that better yet is math.isclose() or numpy.isclose().  Sometimes I'll get into absolute tolerance versus relative tolerance passingly at this point.</div><div><br></div><div>Simply because the edge cases for working with e.g. '<span style="font-size:12.8px">0xC.68p+2' in a hypothetical future Python are less obvious and less simple to demonstrate, I feel like learners will be tempted to think that using this base-2/16 representation saves them all their approximation issues and their need still to use isclose() or friends.</span></div><div><br></div><div><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Sep 21, 2017 at 8:14 PM, Tim Peters <span dir="ltr"><<a href="mailto:tim.peters@gmail.com" target="_blank">tim.peters@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">[David Mertz <<a href="mailto:mertz@gnosis.cx" target="_blank">mertz@gnosis.cx</a>>]<br>
<span>> -1<br>
><br>
> Writing a floating point literal requires A LOT more knowledge than writing<br>
> a hex integer.<br>
<br>
</span>But not really more than writing a decimal float literal in<br>
"scientific notation".  People who use floats are used to the latter.<br>
Besides using "p" instead of "e" to mark the exponent, the only<br>
differences are that the mantissa is expressed in hex instead of in<br>
decimal, and the implicit base to which the exponent is applied is 2<br>
instead of 10.<br>
<br>
Either way it's a notation for a rational number, which may or may not<br>
be exactly representable in the native HW float format.<br>
<span><br>
<br>
> What is the bit length of floats on your specific Python compile? What<br>
> happens if you specify more or less precision than actually available.<br>
> Where is the underflow to subnormal numbers?<br>
<br>
</span>All the same answers apply as when using decimal "scientific<br>
notation".  When the denoted rational isn't exactly representable,<br>
then a maze of rounding, overflow, and/or underflow rules apply.  The<br>
base the literal is expressed in doesn't really have anything to do<br>
with those.<br>
<br>
<br>
> What is the bit representation of [infinity]? Nan?<br>
<br>
Hex float literals in general have no way to spell those:  it's just a<br>
way to spell a subset of (mathematical) rational numbers.  Python,<br>
however, does support special cases for those:<br>
<br>
>>> float.fromhex("inf")<br>
inf<br>
>>> float.fromhex("nan")<br>
nan<br>
<br>
<br>
> -0 vs +0?<br>
<br>
The obvious first attempts work fine for those ;-)<br>
<span><br>
<br>
> There are people who know this and need to know this. But float.fromhex() is<br>
> already available to them. A literal is an attractive nuisance for people<br>
> who almost-but-not-quite understand IEEE-854.<br>
<br>
</span>As notations for rationals, nobody needs to understand 854 at all to<br>
use these things, so long as they stick to exactly representable<br>
numbers.  Whether a specific literal _is_ exactly representable, and<br>
what happens if it's not, does require understanding a whole lot - but<br>
that's also true of decimal float literals.<br>
<span><br>
> I.e. those people who named neither Tim Peters nor Mike Cowlishaw.<br>
<br>
</span>Or Mark Dickinson ;-)<br>
<br>
All that said, I'm -0 on the idea.  I doubt I (or Mark, or Mike) would<br>
use it, because the need is rare and float.fromhex() is already<br>
sufficient.  Indeed, `fromhex()` is less annoying, because it does<br>
support special cases for infinities and NaNs, and doesn't _require_ a<br>
"0x" prefix.<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="m_-469409440412847124gmail_signature" data-smartmail="gmail_signature">Keeping medicines from the bloodstreams of the sick; food <br>from the bellies of the hungry; books from the hands of the <br>uneducated; technology from the underdeveloped; and putting <br>advocates of freedom in prisons.  Intellectual property is<br>to the 21st century what the slave trade was to the 16th.<br></div>
</div>