
Boost : 
From: Sylvain Pion (pion_at_[hidden])
Date: 20020909 10:34:18
On Mon, Sep 09, 2002 at 04:38:51AM 0400, Gennadiy Rozental wrote:
> > Supporting "1/[1;1] = (inf,1] && [1,+inf)" would be nice theoretically.
> > However, consider a basic real world usage : this division is probably not
> the
> > only arithmetic operation involved, and this (already catastrophic) result
> is
> > going to be fed to the following arithmetic operations. For example,
> suppose
> > it is part of the simple function f(x) = 1/x + x. Even with your better
> > multiinterval, f([1;1]) is still going to become [inf;inf] right after
> the
> > following addition. So I do not find this feature important in general.
> > At least this example probably does not justify the complexity of dealing
> with
> > multiintervals.
>
> I am not exactly understand why you brought namely 1/x + x. What if it is
> 1/x + x/2?
You'd get (inf;.5] && [.5;+inf), and it's better than (inf;+inf), right.
My example was just a basic example to show that once you have such a pair of
infinite intervals, IMHO, you are not going very far usefully after that.
That's just my intuition.
Especially if your goal is to test the sign of such an interval...
But well, you may fall back again on a "normal" interval if you do another
division later.
If we want to support this possibility (without multiintervals), we would
probably represent those intervals by swapping the bounds, i.e.
[lower=1;upper=1]. Otherwise we loose in space.
We then have to find something else than [1;0] for the empty interval...
There would also be consequences to handle these intervals properly because the
current code would have to be modified to test for this case, so you would
loose efficiency for the common case I fear.
So we would probably end up introducing a different class R_bar_interval<>,
or something like that.
> > > 5. Interval lacks notion of iterator
> > > I believe it could be convenient in many context to consider interval as
> a
> > > container and accordingly we need the iterators.
> >
> > Why not build an external iterator range from lower() and upper() as you
> > see fit ? That would be much more flexible than any hardcoding that
> > can be done in the interval class, right ?
>
> I can always use lower and upper to do whatever I want.But some default
> simple iterator may worth to add. Note that it will become *much* more
> interesting when you start dealing with multiinterval. Especially would you
> want to support segmented iterators notion from Matt Austern.
What would you propose exactly as a default simple iterator ?
( I'm afraid we're not going to start dealing with multiintervals anyway. )
> > > Implementation:
> > >
> > > 2. namespace interval_lib is confusing.
> > > Everything that is in this library is interval lib. Better name may
> be
> > > interval_policies.
> >
> > It's not only the policies though, constants like pi are there too...
>
> Maybe numeric or numeric_interval. BTW I wanted to ask why interval is not
> located in boost/numeric as ublas do. This are both libraries for numeric
> computations. Note that namely numeric not math, since math is reserved for
> pure math abstractions while numeric deals with rounding, precision and so
> on.
boost::numeric is probably a better fit for the interval class, you are right.
But I guess we need a name for the subnamespace containing the "public
details" (the equivalent of the current boost::interval_lib that you don't
like).
> > > 4. Why constant pi defined only as a double or float. What if I need pi
> as
> > > miltiprecision_double class value? Maybe it should be computed at
> compile
> > > time. You may provide precomputed specialization for intrinsic types.
> >
> > It's also defined for long double (at the same IEEE precision as double
> for
> > now). It's a job for the math constants library anyway. Once Paul
> provides
> > nice lower/upper constants, the interval library will fetch them from
> there.
>
> I don't believe that it will provide you with constant for every
> userdefined number class. As I sad what if I need pi/2 represented as my
> fancy miltiprecision_double class value?
As Guillaume said, there is already a way for the user to provide these
constants.
The IA library cannot do much without proper knowledge of the type in question
(see the work it is just to provide them only for the basic 3 FP types !).
IMHO, this is work for the Math constants library in any case.
 Sylvain
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk