Re: [boost] Formal Review for Interval Library beginning

From: Herve Bronnimann (hbr_at_[hidden])
Date: 2002-09-06 11:46:56

On Fri, Sep 06, 2002 at 12:49:27PM -0300, Fernando Cacciola wrote:
> > This "non-locality" is indeed a problem. But the user should not hesitate
> > to convert an interval to another type with the correct comparison policy.
> >
> True, but the problem is not that a given interval doesn't has the correct
> comparison, but rather that a user doesn't know what it has.
> This is a very important problem for generic code. In my case, all numerical
> algorithm are generic, for example. I can't change the comparison policy
> from within the generic code simply because 'T' might not be
> boost::interval.

Sorry to bulge in your discussion with Guillaume, but I think this is a
point worth highlighting. The issue is about the usage of the library:

  1) Using the type interval in an application (where you have control
  over the definition of intervals yourself)

  2) Using a specialization or overloading of a function with
  interval<T,Traits>, 

  3) Using interval as a template parameter for a numerical routing
  which expects a type T (not necessarily interval).

In designing the library, we allowed users to either choose the meaning
of the comparisons (for case 1) or redirect the interval to one with a
different comparison policy (for case 2) via the template constructor.
Both essentially mean you have control over the comparison.

In case 3, you are saying you may not have control over the comparison.
You may not even know whether the type you are dealing with is T or
interval<T>.

It seems to me for your code to make sense, you need to have some
semantic requirements over T (otherwise by supplying a twisted T, anyone
could make your code behave wildly).  One such reasonable requirement is
that < behaves over interval<T> as it behaves over T, or other numerical
types, float or double for instance.

It seems to me to imply that the Sylvain's position is a the only
desirable one in your case: the default policy should either be no
comparison policy (in order to force the code not to compile) or a
comparison policy which behaves exactly like T if there is no overlap
but otherwise raises an exception.

...

In general, you are correct in saying that the intent of interval<T> is
to behave like the numerical type T (that is why we insist that this is
an Interval **Arithmetic** library). In fact, Sylvain's application is
exactly about using interval<T> instead of T in template code, in order
to catch the cases where intervals do not guarantee a safe result.

I think this broad category of usage, of interval<T> as a numerical
type, should be kept in mind throughout all the discussions. It is what
Sylvain referred to as the __primary__ use of intervals in another
thread.

Just 2 cents of clarification,
-- 
Herve'