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]> 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 > > _______________________________________________ > 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
