On Wednesday, 17 August 2016 at 16:03:22 UTC, H. S. Teoh wrote:
> On Wed, Aug 17, 2016 at 03:44:48AM +0000, Nick B via Digitalmars-d wrote:
>> On Monday, 15 August 2016 at 00:42:16 UTC, H. S. Teoh wrote:
> [...]
>> > Thanks to operator overloading and alias this, we can probably do a pretty good job implementing unums as a library so that people can try it out.
>> 
>> It may be easier to link to the reference C implementation first.
>
> Easier, certainly. But I think D may offer some advantages over a purely C implementation. It's worth exploring, at any rate.

For anyone interested, John Gustafson has posted recently a Powerpoint presentation (dated 2 June 2016), which details the failures (both technical and dollar wise) of Floating Point calculations. At the end of the presentation, he details the state of the current implementations (eg Lawrence Livermore National Lab, and others etc), and the proposed implementations in hardware!


http://www.johngustafson.net/presentations/UnumArithmetic-ICRARseminar.pptx

enjoy.

Nick

On 9/24/16 1:06 AM, Nick B wrote:
> On Wednesday, 17 August 2016 at 11:34:15 UTC, Seb wrote:
>
>>
>> If you want Andrei or Walter's opinion on whether they could in
>> principle imagine Unum as part of Phobos or even the language, you
>> should ping them directly via mail.
>
> Agreed.

From what I read in the freely-available materials on Unum (actually I also skimmed the book) it seems to me Unum is predicated on a hardware implementation. It seems there would be little interest in a slow software emulation. -- Andrei

On Saturday, 24 September 2016 at 12:56:48 UTC, Andrei Alexandrescu wrote:

>
> From what I read in the freely-available materials on Unum (actually I also skimmed the book) it seems to me Unum is predicated on a hardware implementation. It seems there would be little interest in a slow software emulation. -- Andrei

Andrei

I suggest that now, programmers would/may have a choice: be slow and correct, or fast and incorrect, and that would depend if real accuracy is important or not, the types of problems being work on, and cost of failure. (see examples in John Powerpoint presentation).

But I will ask John G, on the types of users showing interest in UNUMS.

Nick

On Sunday, 25 September 2016 at 02:22:01 UTC, Nick B wrote:
>
> But I will ask John G, on the types of users showing interest in UNUMS.
>

I've been interested in it. I've got a copy of the book and I've read some of the papers/ppts. I'm not quite sure why I care about it because as far as I can tell more of my problems have come from speed than accuracy. Nevertheless, I have a big worry that the more calculations you do the greater the probability that small mistakes in accuracy will become bigger problems. Speed lets you do more things, but who knows if the things you do are valid.

On 9/24/16 10:22 PM, Nick B wrote:
> I suggest that now, programmers would/may have a choice: be slow and
> correct, or fast and incorrect, and that would depend if real accuracy
> is important or not, the types of problems being work on, and cost of
> failure.

Let me just say it doesn't seem our policy of "slow but correct" has bore fruit, and I think it's time to dispense with it. There are methods to improve correctness through algorithmic means, but slow primitives you're stuck with. -- Andrei

On Sun, Sep 25, 2016 at 02:22:01AM +0000, Nick B via Digitalmars-d wrote:
> On Saturday, 24 September 2016 at 12:56:48 UTC, Andrei Alexandrescu wrote:
> 
> > 
> > From what I read in the freely-available materials on Unum (actually I also skimmed the book) it seems to me Unum is predicated on a hardware implementation. It seems there would be little interest in a slow software emulation. -- Andrei
> 
> Andrei
> 
> I suggest that now, programmers would/may have a choice: be slow and correct, or fast and incorrect, and that would depend if real accuracy is important or not, the types of problems being work on, and cost of failure.  (see examples in John Powerpoint presentation).
> 
> But I will ask John G, on the types of users showing interest in UNUMS.
[...]

I stand by my previous comment that I think Unum II should be a library implementation in D. It's too early to know whether it will ultimately be the way to go, so adding it to the language (along with all the associated complexity and maintenance costs) doesn't seem like the way to go here. Even putting it into Phobos, I think it's a bit premature. A dub package seems like the best approach at present. I would be quite interested in such a library solution, FWIW. If it turns out to be a good idea, then we can consider putting it into Phobos, or perhaps even the language.  But let's not jump the gun here.


T

-- 
Give me some fresh salted fish, please.

On Sunday, 25 September 2016 at 21:47:15 UTC, H. S. Teoh wrote:
> A dub package seems like the best approach at present. I would be quite interested in such a library solution, FWIW. If it turns out to be a good idea, then we can consider putting it into Phobos, or perhaps even the language.  But let's not jump the gun here.
>
>
> T

Agreed.  This would be a good first step.
Just need to wait for a reference implementation and test cases to be developed, and published.

Nick

On Sunday, 25 September 2016 at 02:22:01 UTC, Nick B wrote:
>
> I suggest that now, programmers would/may have a choice: be slow and correct, or fast and incorrect, and that would depend if real accuracy is important or not, the types of problems being work on, and cost of failure. (see examples in John Powerpoint presentation).
>
> But I will ask John G, on the types of users showing interest in UNUMS.

Hi.
Below is a copy of John's reply, which is interesting and insightful!

[starts]


There are some kinds of problems that can only be solved by unums and not by floats. Initially, those are the main focus. Examples include:

 * Global optimization where proof is needed that all optima have been found

 * Root-finding methods for fully general functions, including non-differentiable functions and other poorly-behaved functions

 * N-body dynamics with rigorous bounds on the orbital trajectories that grow only linearly in the number of time steps

 * Methods that need ultra-fast but ultra-low-precision initial solution with guaranteed mathematical correctness

 * Solutions of systems of nonlinear equations that also reveal whether the problem is stiff or unstable.

It is a misconception, more common than I would like, that the purpose of unums is to substitute for floats in existing floats and then show some kind of superiority. That can happen in terms of getting better answers with fewer bits, and I gave some examples in my book, but they won't be "faster," whatever that means. Floats are a guess about the answer, so they contain no rigorous mathematical bound on the answer; how do I compare their speed at guessing, with the speed of a method that is rigorous? Most people don't even think about the information in an answer as the goal of a benchmark, and just measure the time to finish an algorithm and print a result.

Put another way, if you don't care whether an answer is mathematically correct, then I can compute very fast indeed. Instantly, in fact.

[ends]

Insightful indeed. Of course, these types of problems may be too specialised for the  general D community. I really don't know for sure.

In light of what John has stated above, I should therefore correct my previous statement:

"I suggest that now, programmers going forward will have a choice: be slower with a rigorous mathematical bound answer, or use a fast and incorrect guess, and that would depend if real accuracy is important or not, the types of problems being work on, and the cost of failure".

Nick

On Sunday, 25 September 2016 at 11:00:54 UTC, Andrei Alexandrescu wrote:
> On 9/24/16 10:22 PM, Nick B wrote:
>> I suggest that now, programmers would/may have a choice: be slow and
>> correct, or fast and incorrect, and that would depend if real accuracy
>> is important or not, the types of problems being work on, and cost of
>> failure.
>
> Let me just say it doesn't seem our policy of "slow but correct" has bore fruit, and I think it's time to dispense with it. There are methods to improve correctness through algorithmic means, but slow primitives you're stuck with. -- Andrei

<3

On Saturday, 8 October 2016 at 00:35:31 UTC, Nick B wrote:
> On Sunday, 25 September 2016 at 02:22:01 UTC, Nick B wrote:
>>
>> I suggest that now, programmers would/may have a choice: be slow and correct, or fast and incorrect, and that would depend if real accuracy is important or not, the types of problems being work on, and cost of failure. (see examples in John Powerpoint presentation).
>>
>> But I will ask John G, on the types of users showing interest in UNUMS.
>
> Hi.
> Below is a copy of John's reply, which is interesting and insightful!
>
> [starts]
>
>
> There are some kinds of problems that can only be solved by unums and not by floats. Initially, those are the main focus. Examples include:
>
>  * Global optimization where proof is needed that all optima have been found
>
>  * Root-finding methods for fully general functions, including non-differentiable functions and other poorly-behaved functions
>
>  * N-body dynamics with rigorous bounds on the orbital trajectories that grow only linearly in the number of time steps
>
>  * Methods that need ultra-fast but ultra-low-precision initial solution with guaranteed mathematical correctness
>
>  * Solutions of systems of nonlinear equations that also reveal whether the problem is stiff or unstable.
>
> It is a misconception, more common than I would like, that the purpose of unums is to substitute for floats in existing floats and then show some kind of superiority. That can happen in terms of getting better answers with fewer bits, and I gave some examples in my book, but they won't be "faster," whatever that means. Floats are a guess about the answer, so they contain no rigorous mathematical bound on the answer; how do I compare their speed at guessing, with the speed of a method that is rigorous? Most people don't even think about the information in an answer as the goal of a benchmark, and just measure the time to finish an algorithm and print a result.
>
> Put another way, if you don't care whether an answer is mathematically correct, then I can compute very fast indeed. Instantly, in fact.
>
> [ends]
>
> Insightful indeed. Of course, these types of problems may be too specialised for the  general D community. I really don't know for sure.
>
 I decided to pop this [John G's reply] up again, in case anyone was interested in  * rigorous mathematical bound [solutions] on [an] answer * even if this is for a small D audience.

Nick