Unum II announcement

[Nick B via Digitalmars-d]

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