[boost] Re: Formal Review for Interval Library beginning

From: Gustavo Guerra (gustavobt_at_[hidden])
Date: 2002-09-04 11:26:35

"Sylvain Pion" <pion_at_[hidden]> wrote in message
news:20020903233333.B7125_at_exact.CS.NYU.EDU...
> On Tue, Sep 03, 2002 at 01:10:11PM -0400, Douglas Gregor wrote:
[...]
> > [Comparisons - potential solution]
> > My proposed solution is:
> >   * Use a 3-state boolean type for the result of comparisons between
> > intervals. The 'tribool' type I posted a few weeks ago is one such type
that
> > I believe would give a reasonable semantics.
> >   * Remove comparison policies entirely. With an accepted 3-state
boolean
> > type, there will be one semantics for 3-state boolean values that users
will
> > need to learn, so an interval comparison 'i < j' has a single,
well-defined
> > semantics in terms of 3-state boolean values and its narrowing to a
standard
> > 'bool' will be consistent.
>
> I'm not sure I could live with that proposed solution.  I worked on this
> library in order to generalize my own implementation (which is CGAL's) in
> directions that I was sure would be useful to me or someone else.  With
your
> proposition, this library would not be useful to me anymore, and here
comes
> why :
>
> I agree that the _internal_ logic of tribool is consistent, and I think
> everybody agrees that we need to support it as a possible return type of
the
> comparisons operators.  I would have been happy to get rid of the
> Comparison_policy.  But IMHO, we can't :(
>
> The question is what do you do when you need to convert to a bool, i.e.
what
> does the following do :
>
>   if (x<y)
>
> Obviously, only the indeterminate/overlap case poses a problem.
> Here are the "constraints" for my application :
> - I want to re-use my template code that assumes a comparison is always
safe
>   (i.e. as in the total order of the reals), in short, I don't want to
change a
>   piece of template code that assumes exact arithmetic, and truely boolean
>   comparisons (that's similar to your example basically).
> - I _need_ to be able to detect if there has been some indeterminate
>   comparisons while I was running a piece of code (the whole point of IA).
>   Setting a global variable of throwing an exception are working
alternatives,
>   since I don't want to modify the code of the template function.
>
> The current tribool always converts indeterminate to false without any
> exception or any way to see that, so you _have_ to modify the code to
> explicitly detect the indeterminate case, e.g. using something like :
>
>   if (x<y) {...}
>   else if (!(x<y) {...}
>   else { /* my special case */ }
>
> Hence I can't buy tribool for my application.
>
> On the contrary, the Comparison_policy mecanism allows that, it allows to
> choose the notification by either an exception or setting a global
variable,
> or whatever you want.
>

Just a thought.

What if tribool (or whatever it will be called) had a BoolConversionPolicy
of some kind?
ex:
typedef tribool<indeterminate_converts_to_false> certainly_bool;
typedef tribool<indeterminate_converts_to_true> possibly_bool;

In that case the ComparisonPolicy on interval would be replaced whit the
concrete tribool type or with the tribool policy.
ex:
typedef interval<double, interval_traits<double, compare_certainly<double> >
interval_type;
would be replaced by:
typedef interval<double, certainly_bool, interval_traits<double> >
interval_type;
or
typedef interval<double, indeterminate_converts_to_false,
interval_traits<double> > interval_type;

OTOH, that doesn't really solve the problem as the ComparisonPolicy would
kind of be still there, but camouflated int tribool policy :-/, but It's
another option.

Regards
Gustavo Guerra