Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: Tagged intervals (Was Branch & bound for not everywhere defined constraints)

P1788, George, Arnold

On 5 Sep 2009, at 14:28, Corliss, George wrote:

"Arnold Neumaier" <Arnold.Neumaier@xxxxxxxxxxxx> wrote:

Corliss, George schrieb:
Isn't the P1788 standard for the interval that DecoratedInterval would 
decorate?  That is, our class Interval is the SIMPLE interval. ...

We need to specify what support 1722

[1788, I assume]

should rerquire that enables
programmers later to do with the decorated intervals whatever they want 
to do.
ABSOLUTELY, and I should have made that point. We DO want to include hooks 
essential to building class DecoratedInterval.  I do not really favor
simplest possible; I just oppose overly complicated.

As in most things, Truth lies somewhere between extremes.


If no flags or equivalents for PossiblyUndefined etc. are provide
then a user who wants to program decorated intervals that propagate
a PossiblyUndefined decoration will have to do that the same way as it 
is done now, which means inefficiently and with lots of effort:
every operation must be reprogrammed!

Violently agree.

I also, so far.


I think one consequence of viewing P1788 as a basis for many classes
DecoratedInterval is to prefer the relative simplicity of a flag
PossiblyUndefined (or equivalent) to the relative complexity of multiple 
NaIs, but I'm still listening to the arguments there.
It's not obvious to me that multiple NaIs _are_ more complex, either to use or to code, seeing they are a way to avoid "extra storage" needed by decorations.
My experiments with versions of BIAS showed that the extra IF's needed to support NaI (just a single NaI) impacted performance by under 5%. This was on an Intel Mac, running an extensive C++ benchmark of the VNODE interval ODE solver that I got from Ned Nedialkov. It only used the scalar operations (Bias0 and corresponding elementary functions).
I put this down to the clever branch-prediction method of this hardware, and the fact that NaIs occurred rarely, if at all. If many NaIs were scattered randomly around, I guess the performance hit might be much worse. The message this suggests is: if an application uses scalar interval operations and generates few NaIs, then on modern hardware it won't be much affected by the existence of code in the basic operations that handles NaI. I haven't tried to think what would be the effect in a vector/SIMD situation. 

John