[swift-evolution] [pitch] Comparison Reform

Björn Forster bjoern.forster at googlemail.com
Thu Apr 27 07:14:41 CDT 2017


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


>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> wrote:

>
> > On Apr 22, 2017, at 11:46 PM, David Waite <david at alkaline-solutions.com>
> wrote:
> >
> >> On Apr 22, 2017, at 10:58 PM, Chris Lattner via swift-evolution <
> 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
> 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/20271b0d/attachment.html>


More information about the swift-evolution mailing list