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 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 <matt...@anandabits.com> 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 >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> 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 >>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> 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 >>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >>> >>> > On Apr 22, 2017, at 11:46 PM, David Waite <da...@alkaline-solutions.com >>> > <mailto:da...@alkaline-solutions.com>> wrote: >>> > >>> >> On Apr 22, 2017, at 10:58 PM, Chris Lattner via swift-evolution >>> >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> 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 >>> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>> >>> _______________________________________________ >>> swift-evolution mailing list >>> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >> >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >> https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
