Boost logo

Boost :

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

"Sylvain Pion" <pion_at_[hidden]> wrote in message
> 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
> > I believe would give a reasonable semantics.
> > * Remove comparison policies entirely. With an accepted 3-state
> > type, there will be one semantics for 3-state boolean values that users
> > need to learn, so an interval comparison 'i < j' has a single,
> > semantics in terms of 3-state boolean values and its narrowing to a
> > '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
> proposition, this library would not be useful to me anymore, and here
> 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
> 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.
> 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
> (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
> 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
> or whatever you want.

Just a thought.

What if tribool (or whatever it will be called) had a BoolConversionPolicy
of some kind?
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.
typedef interval<double, interval_traits<double, compare_certainly<double> >
would be replaced by:
typedef interval<double, certainly_bool, interval_traits<double> >
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.

Gustavo Guerra

Boost list run by bdawes at, gregod at, cpdaniel at, john at