Unum II announcement

Nick B via Digitalmars-d digitalmars-d at puremagic.com
Sun Oct 9 22:32:55 PDT 2016


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




More information about the Digitalmars-d mailing list