Re: [boost] Boost.Interval

From: boost (boost_at_[hidden])
Date: 2001-04-24 11:49:36

Salut,

> > You will need just one function call to check if x has a
> > zero in the interval -1..1:
>
> "just one function call" could mean millions of instructions. Did you mean
> to say something else?
Let it be 100 millions, the number of instructions is finite.
The point is that the evalution of an interval should not
be more than order of magnitude slower than that of an ordinary functions.

in addition it's a matter of hardware, e.g.
http://www.uni-karlsruhe.de/~iam/cavn/flyer_eng.html

> Knowing that a zero exists doesn't help me to find the zero, does it?
Just bisection your interval. 
> Knowing that no zero exists might be useful so that I can give up and try
> something else, but it doesn't solve my main problem, which is finding x
> s.t. f(x) = 0 when such a zero does exist.
Maybe you have been lucky with your calculations but I had to fight
with a tremendous amount of badly behaved functions, e.g. singualrities
which open a second non-physical solution, which attracted all my non-interval
based methods. Or think of root searching of functions with 2 or 3 variables

> I have no argument that interval arithmetic is useful. It's just unclear to
> me that its useful for solving the type of problem I'm working on, much
> less a substitute for single-valued calculations in all circumstances.

Actually it's far from beeing clear, but AFAIK there are algorithm where 
interval arithmetics is faster than normal arithmetics, it's just something
that's not widly known, maybe experts can give more precise information.
Just using
#define double interval<double>
won't be enough.
I don't know what you're working on n'or am i an interval expert, but let me 
add one more comment:
A few years ago I did large scale computational physics diagonalizing 
extremly big matrices. everything was stable, no singularities, nothing to 
worry but computing time. Well, it turned out that even in this case the
ibm rs6k with a FusedMultiplyAdd unit always had a slighly more accurate
result than other machines (SGI indigo, SGI Origin, T3E).  (Most of the time 
was spent in dgemm)

Best wishes,
Peter