<div dir="ltr">Hi all together, <div>I was just looking quickly over an article from Wolfram which covers new books covering Mathematica and tripped over this book:</div><div><br></div><div><a href="https://www.crcpress.com/The-End-of-Error-Unum-Computing/Gustafson/p/book/9781482239867">https://www.crcpress.com/The-End-of-Error-Unum-Computing/Gustafson/p/book/9781482239867</a></div><div><br></div><div><br></div><div>From the reviews:</div><span style="color:rgb(51,51,51);font-family:opensans,helvetica,arial,sans-serif;font-size:14px">&quot;This book is an extraordinary reinvention of computer arithmetic and elementary numerical methods from the ground up. Unum arithmetic is an extension of floating point in which it is also possible to represent the open intervals </span><i style="box-sizing:border-box;color:rgb(51,51,51);font-family:opensans,helvetica,arial,sans-serif;font-size:14px">between</i><span style="color:rgb(51,51,51);font-family:opensans,helvetica,arial,sans-serif;font-size:14px"> two floating point numbers. This leads to arithmetic that is algebraically much cleaner, without rounding error, overflow underflow, or negative zero, and with clean and consistent treatment of positive and negative infinity and NaN. These changes are not just marginal technical improvements. As the book fully demonstrates, they lead to what can only be described as a radical re-foundation of elementary numerical analysis, with new methods that are free of rounding error, fully parallelizable, fully portable, easier for programmers to master, and often more economical of memory, bandwidth, and power than comparable floating point methods. The book is exceptionally well written and produced and is illustrated on every page with full-color diagrams that perfectly communicate the material. Anyone interested in computer arithmetic or numerical methods must read this book. It is surely destined to be a classic.&quot;</span><br style="box-sizing:border-box;color:rgb(51,51,51);font-family:opensans,helvetica,arial,sans-serif;font-size:14px"><div><span style="color:rgb(51,51,51);font-family:opensans,helvetica,arial,sans-serif;font-size:14px">—David Jefferson, Center for Advanced Scientific Computing, Lawrence Livermore National Laboratory</span> </div><div><br></div><div>I haven&#39;t read it myself, as said I stepped just over it, but *MAYBE* it covers the NaN problem in depth and the current state of art how to deal with it. </div><div>Maybe someone has free access to an online library (maybe via some university enrollment) and can have a look at it?</div><div><br></div><div>- Björn </div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Apr 23, 2017 at 4:40 PM, Chris Lattner via swift-evolution <span dir="ltr">&lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
&gt; On Apr 22, 2017, at 11:46 PM, David Waite &lt;<a href="mailto:david@alkaline-solutions.com">david@alkaline-solutions.com</a>&gt; wrote:<br>
&gt;<br>
&gt;&gt; On Apr 22, 2017, at 10:58 PM, Chris Lattner via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; I don’t think that this proposal is acceptable as written.  I think it is really bad that abstracting a concrete algorithm would change its behavior so substantially.  I don’t care about SNaNs, but I do care about the difference between +0/-1 and secondarily that of NaN handling.  It seems really bad that generalizing something like:<br>
&gt;&gt;<br>
&gt;&gt; func doThing(a : Double, b : Double) -&gt; Bool {<br>
&gt;&gt;  ….<br>
&gt;&gt;  return a != b<br>
&gt;&gt; }<br>
&gt;&gt;<br>
&gt;&gt; to:<br>
&gt;&gt;<br>
&gt;&gt; func doThing&lt;T : FloatingPoint&gt; (a : T, b : T) -&gt; Bool {<br>
&gt;&gt;  ….<br>
&gt;&gt;  return a != b<br>
&gt;&gt; }<br>
&gt;&gt;<br>
&gt;&gt; would change behavior (e.g. when a is -0.0 and b is +0.0).   Likewise, &quot;T : Equatable”.<br>
&gt;<br>
&gt; Did I misunderstand the proposal? If T : FloatingPoint is not included in level 1 comparisons, then you cannot have classes of generic floating point algorithms.<br>
<br>
Sorry about that, my mistake, I meant “T: Comparable&quot;<br>
<br>
-Chris<br>
______________________________<wbr>_________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br>
</blockquote></div><br></div>