<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><br>Sent from my iPhone</div><div><br>On 28 Apr 2017, at 01:51, Jonathan Hull via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br><br></div><blockquote type="cite"><div><meta http-equiv="Content-Type" content="text/html charset=utf-8">To be clear, the big downside is the current lack of hardware support. There are apparently some chips in the pipeline, but nothing for Apple platforms that I know of. </div></blockquote><div><br></div><div>Synergy between HW and SW... fully custom ARMv8 cores... wink wink... nudge nudge ;). Maybe if they become super important for Swift there is an economic advantage for their own chips to push for them (Desktop and MacBook are more of an issue and depend on a whole other set of factors to happen).</div><br><blockquote type="cite"><div>We are likely to see them first in GPUs and neural network processors (since they allow effective neural networks using only 8-bit values, and the binary representation dramatically simplifies some standard neural network calculations). Most language implementations currently use a backing Int as storage.<div class=""><br class=""></div><div class="">That said, I think it is still a worthwhile pursuit, especially for those of us interested in accurate numerical calculations. According to the author, they should also be able to be used interchangeably with Floats in any generic algorithm, though the results would differ (because of the increased accuracy/range). I am still reading to find the details.</div><div class=""><br class=""></div><div class="">If we are interested, I think the first step would be making a third party library...</div><div class=""><br class=""></div><div class="">Thanks,</div><div class="">Jon<br class=""><div class=""><br class=""></div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Apr 27, 2017, at 4:35 PM, Jonathan Hull via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">There have been a bunch of updates since then (currently under peer review), which deal with implementation on current systems. Reading the new/updated paper now…<div class=""><br class=""></div><div class="">Here is a video of the author speaking about some of the general ideas:</div><div class=""><a href="https://www.youtube.com/watch?v=aP0Y1uAA-2Y" class="">https://www.youtube.com/watch?v=aP0Y1uAA-2Y</a><br class=""><div class=""><br class=""></div><div class="">I doubt we would get rid of Double/Float, but I would love to see it used as a core type in Swift 5. In addition to the increase in accuracy/expressible range, and the simplification of exception handling, apparently the results when used in neural networks are amazing. It also allows you to simplify a bunch of numerical algorithms, because you don’t have to worry about some of the things that go wrong with traditional floats/doubles.</div><div class=""><br class=""></div><div class="">Thanks,</div><div class="">Jon</div><div class=""><br class=""></div><div class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Apr 27, 2017, at 2:35 PM, Matthew Johnson <<a href="mailto:matthew@anandabits.com" class="">matthew@anandabits.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">I mentioned unums on the list about a year ago. Steve Canon replied with some thoughts: <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160509/016889.html" class="">https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160509/016889.html</a>.</div><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Apr 27, 2017, at 4:26 PM, Jonathan Hull via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">I have read it, and it is a truly brilliant work. I would love to see some (or all) of it make it into Swift (most likely Swift 5 or 6). The author is related to a friend of mine, so I can see if he is available to answer questions if there is interest...<div class=""><br class=""></div><div class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Apr 27, 2017, at 5:14 AM, Björn Forster via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">Hi all together, <div class="">I was just looking quickly over an article from Wolfram which covers new books covering Mathematica and tripped over this book:</div><div class=""><br class=""></div><div class=""><a href="https://www.crcpress.com/The-End-of-Error-Unum-Computing/Gustafson/p/book/9781482239867" class="">https://www.crcpress.com/The-End-of-Error-Unum-Computing/Gustafson/p/book/9781482239867</a></div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">From the reviews:</div><span style="color:rgb(51,51,51);font-family:opensans,helvetica,arial,sans-serif;font-size:14px" class="">"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" class="">between</i><span style="color:rgb(51,51,51);font-family:opensans,helvetica,arial,sans-serif;font-size:14px" class=""> 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."</span><br style="box-sizing:border-box;color:rgb(51,51,51);font-family:opensans,helvetica,arial,sans-serif;font-size:14px" class=""><div class=""><span style="color:rgb(51,51,51);font-family:opensans,helvetica,arial,sans-serif;font-size:14px" class="">—David Jefferson, Center for Advanced Scientific Computing, Lawrence Livermore National Laboratory</span> </div><div class=""><br class=""></div><div class="">I haven'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 class="">Maybe someone has free access to an online library (maybe via some university enrollment) and can have a look at it?</div><div class=""><br class=""></div><div class="">- Björn </div></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Sun, Apr 23, 2017 at 4:40 PM, Chris Lattner via swift-evolution <span dir="ltr" class=""><<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br class="">
> On Apr 22, 2017, at 11:46 PM, David Waite <<a href="mailto:david@alkaline-solutions.com" class="">david@alkaline-solutions.com</a>> wrote:<br class="">
><br class="">
>> On Apr 22, 2017, at 10:58 PM, Chris Lattner via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class="">
>><br class="">
>> 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 class="">
>><br class="">
>> func doThing(a : Double, b : Double) -> Bool {<br class="">
>> ….<br class="">
>> return a != b<br class="">
>> }<br class="">
>><br class="">
>> to:<br class="">
>><br class="">
>> func doThing<T : FloatingPoint> (a : T, b : T) -> Bool {<br class="">
>> ….<br class="">
>> return a != b<br class="">
>> }<br class="">
>><br class="">
>> would change behavior (e.g. when a is -0.0 and b is +0.0). Likewise, "T : Equatable”.<br class="">
><br class="">
> 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 class="">
<br class="">
Sorry about that, my mistake, I meant “T: Comparable"<br class="">
<br class="">
-Chris<br class="">
______________________________<wbr class="">_________________<br class="">
swift-evolution mailing list<br class="">
<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/<wbr class="">mailman/listinfo/swift-<wbr class="">evolution</a><br class="">
</blockquote></div><br class=""></div>
_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></blockquote></div><br class=""></div></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></blockquote></div><br class=""></div></div></blockquote></div><br class=""></div></div></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></blockquote></div><br class=""></div></div></div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote></body></html>