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]> 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] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
