RE: [boost] Formal Review for Interval Library beginning

From: David Bergman (davidb_at_[hidden])
Date: 2002-09-06 14:39:08

Guillaume,

One often attaches semantics to the syntactical operators. The semantics
one attaches to '<' is usually a relation, which has nothing to do with
tribool comparisons. So, either a pair belongs to this relation or not.
You want it to denote a non-relation.

I agree with Fernando in that if the user wants to fetch the
indeterminate case, he/she cannot use a binary relation.

You want '<' to denote a function to a a 3-space, which is not obvious
for a user, IMEHO.

So, we seem to be torn by two counter-intuitive extremes: (1) defining
'<' not as a relation, but as a binary function into a 3-space and (2)
using a "unnatural" total ordering (e.g., lexicographic) for '<'.

Which extreme do you prefer?

My bias is clear, (2), with a proper disclaimer.

/David

-----Original Message-----
From: boost-bounces_at_[hidden]
[mailto:boost-bounces_at_[hidden]] On Behalf Of Guillaume Melquiond
Sent: Friday, September 06, 2002 2:23 PM
To: boost_at_[hidden]
Subject: Re: [boost] Formal Review for Interval Library beginning

On Fri, 6 Sep 2002, Fernando Cacciola wrote:

> > Let's put it simply: the result of a comparison (in the 
> > forall/exists context used in static analysis and inequations 
> > systems solving) is an element of {false, maybe, true}. You need 
> > three different values; and if you map it to {false, true} before 
> > returning it to the user, he/she will lose a part of the 
> > information.
> >
> he/she is a part of the running program? I ask because in Doug's 
> response I couldn't see the usage for the program itself.

Here is a little solver for the inequation 'f(x) > 0':

  void solve(interval x) {
    tribool cmp = f(x) > 0;
    if (f == true) {
      // we have a winner, let's warn the user
      throw x;
    } else if (f == false) {
      // to bad, we are sure there is no solution in x
      return;
    } else {
      // maybe there is a solution, let's bisect to be sure
      std::pair<interval> p = bisect(x);
      solve(p.first);
      solve(p.second);
    }
  }

The function will throw an exception when it found a solution.

> > By using a more complex type than bool, you can store this 
> > three-states information. And the problem of this type being 
> > convertible or not to bool afterwards is not really relevant here. 
> > What is interesting with tribool is that it holds a three-states 
> > value, not that it is convertible to bool.
> >
> Are you thinking of this?
> 
> tribool rel = x < y ;
> assert ( !indeterminate(rel) ) ;
> if ( rel ) less() else not_less();
> 
> If so, isn't it already possible to achieve this with the comparison 
> functions?

Yes it is. But this whole thread was not about the comparison functions
but the comparison operators.

> That is, if the user (not an external tool, but a part of the running
> program) needs to explicitely test for the indeterminate case, why 
> would (s)he use operator <?

Why are we using using '+' even though we could have an 'add' function
and call it? It's the same problem.

Just think that the solver could solve 'f(x) > 0 && g(x) > 0'. So the
first line of the function body would be:

  tribool cmp = f(x) > 0 && g(x) > 0;

Don't you think it's quite a readable way to write it?

Regards,

Guillaume

_______________________________________________
Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost