Sent from my iPhone > On 28 Apr 2017, at 01:51, Jonathan Hull via swift-evolution > <[email protected]> wrote: > > To be clear, the big downside is the current lack of hardware support. There > are apparently some chips in the pipeline, but nothing for Apple platforms > that I know of.
Synergy between HW and SW... fully custom ARMv8 cores... wink wink... nudge nudge ;). Maybe if they become super important for Swift there is an economic advantage for their own chips to push for them (Desktop and MacBook are more of an issue and depend on a whole other set of factors to happen). > We are likely to see them first in GPUs and neural network processors (since > they allow effective neural networks using only 8-bit values, and the binary > representation dramatically simplifies some standard neural network > calculations). Most language implementations currently use a backing Int as > storage. > > That said, I think it is still a worthwhile pursuit, especially for those of > us interested in accurate numerical calculations. According to the author, > they should also be able to be used interchangeably with Floats in any > generic algorithm, though the results would differ (because of the increased > accuracy/range). I am still reading to find the details. > > If we are interested, I think the first step would be making a third party > library... > > Thanks, > Jon > > >> On Apr 27, 2017, at 4:35 PM, Jonathan Hull via swift-evolution >> <[email protected]> wrote: >> >> 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 <[email protected]> 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. >>> >>>> 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]> 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 >>>>> >>>>> >>>>> 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]> wrote: >>>>>> >>>>>> > On Apr 22, 2017, at 11:46 PM, David Waite >>>>>> > <[email protected]> wrote: >>>>>> > >>>>>> >> On Apr 22, 2017, at 10:58 PM, Chris Lattner via swift-evolution >>>>>> >> <[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] >>>>>> 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 >>> >> >> _______________________________________________ >> 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
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
