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. 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.
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. If we are interested, I think the first step would be making a third party library... Thanks, Jon > On Apr 27, 2017, at 4:35 PM, Jonathan Hull via swift-evolution > <[email protected]> wrote: > > 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… > > Here is a video of the author speaking about some of the general ideas: > https://www.youtube.com/watch?v=aP0Y1uAA-2Y > <https://www.youtube.com/watch?v=aP0Y1uAA-2Y> > > 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. > > Thanks, > Jon > > >> On Apr 27, 2017, at 2:35 PM, Matthew Johnson <[email protected]> wrote: >> >> I mentioned unums on the list about a year ago. Steve Canon replied with >> some thoughts: >> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160509/016889.html >> >> <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160509/016889.html>. >> >>> On Apr 27, 2017, at 4:26 PM, Jonathan Hull via swift-evolution >>> <[email protected] <mailto:[email protected]>> wrote: >>> >>> 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... >>> >>> >>>> On Apr 27, 2017, at 5:14 AM, Björn Forster via swift-evolution >>>> <[email protected] <mailto:[email protected]>> wrote: >>>> >>>> Hi all together, >>>> I was just looking quickly over an article from Wolfram which covers new >>>> books covering Mathematica and tripped over this book: >>>> >>>> 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> >>>> >>>> >>>> From the reviews: >>>> "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 between 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." >>>> —David Jefferson, Center for Advanced Scientific Computing, Lawrence >>>> Livermore National Laboratory >>>> >>>> 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. >>>> Maybe someone has free access to an online library (maybe via some >>>> university enrollment) and can have a look at it? >>>> >>>> - Björn >>>> >>>> On Sun, Apr 23, 2017 at 4:40 PM, Chris Lattner via swift-evolution >>>> <[email protected] <mailto:[email protected]>> wrote: >>>> >>>> > On Apr 22, 2017, at 11:46 PM, David Waite <[email protected] >>>> > <mailto:[email protected]>> wrote: >>>> > >>>> >> On Apr 22, 2017, at 10:58 PM, Chris Lattner via swift-evolution >>>> >> <[email protected] <mailto:[email protected]>> wrote: >>>> >> >>>> >> 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: >>>> >> >>>> >> func doThing(a : Double, b : Double) -> Bool { >>>> >> …. >>>> >> return a != b >>>> >> } >>>> >> >>>> >> to: >>>> >> >>>> >> func doThing<T : FloatingPoint> (a : T, b : T) -> Bool { >>>> >> …. >>>> >> return a != b >>>> >> } >>>> >> >>>> >> would change behavior (e.g. when a is -0.0 and b is +0.0). Likewise, >>>> >> "T : Equatable”. >>>> > >>>> > 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. >>>> >>>> Sorry about that, my mistake, I meant “T: Comparable" >>>> >>>> -Chris >>>> _______________________________________________ >>>> swift-evolution mailing list >>>> [email protected] <mailto:[email protected]> >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>>> >>>> _______________________________________________ >>>> swift-evolution mailing list >>>> [email protected] <mailto:[email protected]> >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>> >>> _______________________________________________ >>> swift-evolution mailing list >>> [email protected] <mailto:[email protected]> >>> https://lists.swift.org/mailman/listinfo/swift-evolution >> > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
