Re: [boost] Formal Review for Interval Library beginning

From: Fernando Cacciola (fcacciola_at_[hidden])
Date: 2002-09-06 13:11:04

----- Original Message -----
From: "Herve Bronnimann" <hbr_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Friday, September 06, 2002 1:46 PM
Subject: Re: [boost] Formal Review for Interval Library beginning

> 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).
Absolutely.
Although I will also choose not to use ambiguous tools such as operator <
for generic types which are not required to be totally ordered.
I said in my first post that I use relational operators in generic code ONLY
if I can guarantee that such operators will have a unique consistent
semantic AND that ALL expected (by me) identities (such as '<=' befing '<'
or '==') hold.
For instance, in my generic numerical algorithms I never use relational
operators to express conditional relations bewteen generic numbers. I always
use Numeric Comparator objects, which use function call syntax only. These
comparators are passed as additional template arguments so the comparison
semantic is not attached to the number type.

Similarly, when I need to use these generic numbers as keys, I supply
specific function-objects.
I don't try to make std::less<> work by specializing it (because I agree
that std::less should be just '<' inside an object)
nor do I try to let the container work by leaving it with a default
comparator.

> One such reasonable requirement is
> that < behaves over interval<T> as it behaves over T, or other numerical
> types, float or double for instance.
>
Indeed, altough I'm not sure if such a correspondence is easy to find
consensually.

> 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.
>
Yes. I totally agree with him here.
By default it should only result in true/false (indeterminate should throw),
and true should imply no overlapping.
Or else it should be no default.

>
>
>
>
> 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.
>
I agree.
I think that interval<T>'s main purpose is to replace FP types attaching
them with some degree of roundoff traceback.

This BTW answers Douglas question about which is the interface for this
particularly targeted interval class.
(And I agree with him that the discussion should be focused into the
library's target).

Fernando Cacciola
Sierra s.r.l.
fcacciola_at_[hidden]
www.gosierra.com