On Monday, 13 July 2015 at 21:25:12 UTC, Per Nordlöw wrote:

> Can we do anything useful with unums in numeric algorithms if only have forward or bidirectional access? Similar to algorithms such as Levenshtein that are compatible with UTF-8 and UTF-16, Andrei? :)

Question for Andrei, above, if he would like to reply.

On 7/16/15 9:49 PM, Nick B wrote:
> On Monday, 13 July 2015 at 21:25:12 UTC, Per Nordlöw wrote:
>
>> Can we do anything useful with unums in numeric algorithms if only
>> have forward or bidirectional access? Similar to algorithms such as
>> Levenshtein that are compatible with UTF-8 and UTF-16, Andrei? :)
>
> Question for Andrei, above, if he would like to reply.

Haven't gotten to reading about unum, so I'm a bit lost. Who has forward/bidirectional access? -- Andrei

On 7/13/15 1:20 AM, Nick B wrote:
> On Sunday, 12 July 2015 at 03:52:32 UTC, jmh530 wrote:
>> On Saturday, 11 July 2015 at 03:02:24 UTC, Nick B wrote:
>>>
>>> FYI
>>>
>>> John Gustafson book is now out:
>>
>> I wouldn't have known about this way to deal with it if you hadn't
>> bumped this thread. So thanks, it's interesting (not sure if this book
>> will adequately address Walter's original concern that it won't really
>> reduce power consumption). I also found the discussion of rational
>> numbers earlier in the thread interesting.
>
> I glad that you guys have found this interesting :)
>
> Nick

Just read http://radiofreehpc.com/tmp/TheEndofErrorSampleChapter.pdf, very interesting stuff. I assume the definition of various primitives for unum are as compelling as alluded.

The treatment angles toward a hardware representation and primitives, yet these ideas seem reasonably actionable at language level. We'd be able to implement the primitives in software, and the result would be a competitor for infinite-precision arithmetic libraries, which do exist and are being used. Yet the software implementation would be very slow compared to IEEE floats, which limits applications quite a bit.

All we can do now, with our limited resources, is to keep an eye on developments and express cautious interest. If someone able and willing comes along with a unum library for D, that would be great.


Andrei

On Wednesday, 22 July 2015 at 19:28:41 UTC, Andrei Alexandrescu wrote:
> On 7/13/15 1:20 AM, Nick B wrote:
>
> All we can do now, with our limited resources, is to keep an eye on developments and express cautious interest. If someone able and willing comes along with a unum library for D, that would be great.
>

The book has quite a bit of Mathematica code at the end. A first pass at a unum library could probably just involve porting that to D.

On Wednesday, 22 July 2015 at 20:41:42 UTC, jmh530 wrote:
> On Wednesday, 22 July 2015 at 19:28:41 UTC, Andrei Alexandrescu wrote:
>> On 7/13/15 1:20 AM, Nick B wrote:
>>
>> All we can do now, with our limited resources, is to keep an eye on developments and express cautious interest. If someone able and willing comes along with a unum library for D, that would be great.
>>
>
> The book has quite a bit of Mathematica code at the end. A first pass at a unum library could probably just involve porting that to D.

Here is a Python port of the Mathematica code which is that much closer to D:
https://github.com/jrmuizel/pyunum

Regardless of whether the representation used follows the unum bitwise format proposed in the book, having the semantics of interval arithmetic that keeps proper account of amount of precision, and exact values vs. open/closed ended intervals on the extended real line would be quite valuable for verified computation and for how it enables simple root finding / optimization / differential equation solving via search, and could build on hard float directly andor an extended precision float library such as MPFR to keep performance close to raw floats.

The bitwise format is intended to fit as much data as possible through the time-energy bottleneck between main memory and the processor. This would clearly be of great value if the format were supported in hardware but of less clear value otherwise. The semantic improvements would be quite welcome regardless. They go much further than best practices with floats to put error bounds on computations, handle over/underflow and infinity correctly, and keep algorithms correct by default. We might also consider small semantic improvements if not rigidly bound by the proposed formats and the need to implement in hardware, such as having division by an interval including zero return the union of the results from the intervals on either side of the zero as well as NaN (1-D intervals are strictly represented as the convex hull of at most two points in the proposed format, so an interval such as this made of a sentinel value unified with two disjoint intervals, though it has better semantics, is not supported).

Anthony

On Saturday, 11 July 2015 at 03:02:24 UTC, Nick B wrote:
> On Thursday, 20 February 2014 at 10:10:13 UTC, Nick B wrote:
>>
>> Hi everyone.
>>
>
>> John Gustafson Will be presenting a Keynote on Thursday 27th February at 11:00 am
>>
>> The abstract is here:  http://openparallel.com/multicore-world-2014/speakers/john-gustafson/
>>
>> There is also a excellent background paper, (PDF - 64 pages) which can be found here:
>>
>
> FYI
>
> John Gustafson book is now out:
>
> It can be found here:
>
> http://www.amazon.com/End-Error-Computing-Chapman-Computational/dp/1482239868/ref=sr_1_1?s=books&ie=UTF8&qid=1436582956&sr=1-1&keywords=John+Gustafson&pebp=1436583212284&perid=093TDC82KFP9Y4S5PXPY
>
>
> Here is one of the reviewers comments:
>
> 9 of 9 people found the following review helpful
>
> This book is revolutionary
> By David Jefferson on April 18, 2015
>
> This book is revolutionary. That is the only way to describe it. I have been a professional computer science researcher for almost 40 years, and only once or twice before have I seen a book that is destined to make such a profound change in the way we think about computation. It is hard to imagine that after 70 years or so of computer arithmetic that there is anything new to say about it, but this book reinvents the subject from the ground up, from the very notion of finite precision numbers to their bit-level representation, through the basic arithmetic operations, the calculation of elementary functions, all the way to the fundamental methods of numerical analysis, including completely new approaches to expression calculation, root finding, and the solution of differential equations. On every page from the beginning to the end of the book there are surprises that just astonished me, making me re-think material that I thought had been settled for decades.
>
> The methods described in this book are profoundly different from all previous treatments of numerical methods. Unum arithmetic is an extension of floating point arithmetic, but mathematically much cleaner. It never does rounding, so there is no rounding error. It handles what in floating point arithmetic is called "overflow" and "underflow" in a far more natural and correct way that makes them normal rather than exceptional. It also handles exceptional values (NaN, +infinity, -infinity) cleanly and consistently. Those contributions alone would have been a profound contribution. But the book does much more.
>
> One of the reasons I think the book is revolutionary is that unum-based numerical methods can effortlessly provide provable bounds on the error in numerical computation, something that is very rare for methods based on floating point calculations. And the bounds are generally as tight as possible (or as tight as you want them), rather than the useless or trivial bounds as often happens with floating point methods or even interval arithmetic methods.
>
> Another reason I consider the book revolutionary is that many of the unum-based methods are cleanly parallelizable, even for problems that are normally considered to be unavoidably sequential. This was completely unexpected.
>
> A third reason is that in most cases unum arithmetic uses fewer bits, and thus less power, storage, and bandwidth (the most precious resources in today’s computers) than the comparable floating point calculation. It hard to believe that we get this advantage in addition to all of the others, but it is amply demonstrated in the book. Doing efficient unum arithmetic takes more logic (e.g. transistors) than comparable floating point arithmetic does, but as the author points out, transistors are so cheap today that that hardly matters, especially when compared to the other benefits.
>
> Some of the broader themes of the book are counterintuitive to people like me advanced conventional training, so that I have to re-think everything I “knew” before. For example, the discussion of just what it means to “solve” an equation numerically is extraordinarily thought provoking. Another example is the author’s extended discussion of how calculus is not the best inspiration for computational numerical methods, even for problems that would seem to absolutely require calculus-based thinking, such as the solution of ordinary differential equations.
>
> Not only is the content of the book brilliant, but so is the presentation. The text is so well written, a mix of clarity, precision, and reader friendliness that it is a pure pleasure to read, rather then the dense struggle that mathematical textbooks usually require of the reader. But in addition, almost every page has full color graphics and diagrams that are completely compelling in their ability to clearly communicate the ideas. I cannot think of any technical book I have ever seen that is so beautifully illustrated all the way through.
>
> I should add that I read the Kindle edition on an iPad, and for once Amazon did not screw up the presentation of a technical book, at least for this platform. It is beautifully produced, in full color and detail, and with all of the fonts and graphics reproduced perfectly.
>
> Dr. Gustafson has also provided a Mathematica implementation of unums and of the many numerical methods discussed in the book. Let us hope that in the next few years there will be implementations in other languages, followed by hardware implementations. Over time there should be unum arithmetic units alongside of floating point arithmetic units on every CPU and GPU chip, and in the long run unums should replace floating point entirely. The case the author makes for this is overwhelming.
>
> If you are at all interested in computer arithmetic or numerical methods, read this book. It is destined to be a classic.

To be honest, that sound like snake oil salesman speech to me rather than science. It's all hand waving and nothing concrete is provided, the whole thing wrapped in way too much superlatives.

The guy seems to have good credential. Why should I read that book ?

On Tuesday, 15 September 2015 at 05:16:53 UTC, deadalnix wrote:
>
> The guy seems to have good credential. Why should I read that book ?

The sample chapter dissipates a bit the marketing cloud.
One of the ideas is that the imprecise bit encode an interval between 2 values, hence automatically computing the "precision" of a computation without analysis.

On Tuesday, 15 September 2015 at 07:07:20 UTC, ponce wrote:
> On Tuesday, 15 September 2015 at 05:16:53 UTC, deadalnix wrote:
>>
>> The guy seems to have good credential. Why should I read that book ?
>
> The sample chapter dissipates a bit the marketing cloud.
> One of the ideas is that the imprecise bit encode an interval between 2 values, hence automatically computing the "precision" of a computation without analysis.

Read it. That is suddenly much less impressive, but much more sensible.

On Tuesday, 15 September 2015 at 07:57:01 UTC, deadalnix wrote:
> On Tuesday, 15 September 2015 at 07:07:20 UTC, ponce wrote:
>> On Tuesday, 15 September 2015 at 05:16:53 UTC, deadalnix wrote:
>>>
>>> The guy seems to have good credential. Why should I read that book ?
>>
>> The sample chapter dissipates a bit the marketing cloud.
>> One of the ideas is that the imprecise bit encode an interval between 2 values, hence automatically computing the "precision" of a computation without analysis.
>
> Read it. That is suddenly much less impressive, but much more sensible.

I can see this being useful since nowadays in the native space we often choose between single and double precision with ad-hoc oral rules and learned habits rather than measuring precision.

However if unum aren't fast, they will be only for prototyping and the real algorithm would rely on IEEE floats with different precision characteristics, so yeah hardware is critical.

On Tuesday, 15 September 2015 at 08:24:30 UTC, ponce wrote:
> However if unum aren't fast, they will be only for prototyping and the real algorithm would rely on IEEE floats with different precision characteristics, so yeah hardware is critical.


I think he is looking into 32 bit floats for a simpler version of the concept combined with the "ubox" method (multidimensional interval representation that "brute force" the answer). The "uboxing" is visualized here:

http://sites.ieee.org/scv-cs/files/2013/03/Right-SizingPrecision1.pdf