Re: [boost] Formal Review for Interval Library beginning

From: Herve Bronnimann (hbr_at_[hidden])
Date: 2002-09-03 15:02:50

On Tue, Sep 03, 2002 at 08:50:26PM +0200, Guillaume Melquiond wrote:
> Yes, it's something that can be done. And it will probably be done. It's
> only a matter of changing the return type of the comparison operators and
> the impact on the interface is quite minimal.
>
> Yes, the library will be modified to allow the return type of the
> comparison operators to be chosen by the user.
> 
> However, the version being reviewed will not be changed. Only the CVS will
> see the changes.

> >   * 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.
> 
> Entirely remove the comparison policy? You want the 3-state boolean
> type to be fixed by the interval library? :-)

Reading from Guillaume's message, I want to clarify that: we will enable
comparison policies to choose their return type, and add a new compare
policy that will return a tribool (if this type is defined, to avoid
dependency problems for those who don't use the sandbox's tribool.hpp).

We might rename compare_full into compare_trigger<..,Function>  (because
it triggers a function call when the result is indeterminate) and call
the new policy compare_tribool<..>. Would that satisfy everyone?

> >   * Remove cer?? and pos?? functions. 3-state boolean values can be queried 
> > directly to determine if they are false, indeterminate, or true. Without 
> > comparison policies, conversions to 'bool' are predictable.
> 
> I'm against the removal of the explicit comparison functions. Please
> understand that such a function only needs one number comparison to know
> what to answer. A comparison operator returning a tristate boolean may
> need two numbers comparison before answering (and depending on the
> compiler, maybe one more to convert it to bool). So they are really
> fastest.

I second Guillaume here. Much effort was made to achieve the best
performance in many settings (unprotected mode, etc.). It would be sad
if this was wasted for the comparisons. However, I have a proposal for
the lisibility.

> In certain situations, it can even add lisibility to the program. For
> example, how will you write poslt(x,y)? I'm not sure your answer will be
> more readable.

At some stage in the discussion, it was proposed to rename those to long
names: certainly_greater_than (cergt), possibly_less_than (poslt),
certainly_not_more_than (cerle), etc.

The synopsis in the documentation is a bit long, because of the number
of combinations,  but could be abridged by just stating the function
names. I put it there just in case some automatic tool wanted to extract
synopsis, or such. But I myself agree it's not a necessary evil.

Also, one item that popped up is: should these functions belong to
boost:: or to boost::interval_lib ? Moving them to interval_lib might
also avoid polluting the namespace boost.
-- 
Hervé