[swift-evolution] [pitch] Comparison Reform

[Matthew Johnson]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170427/470cf77a/attachment.html>