Unum II announcement
Nick B via Digitalmars-d
digitalmars-d at puremagic.com
Fri Oct 7 17:35:31 PDT 2016
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
More information about the Digitalmars-d
mailing list