Re: [boost] Formal Review for Interval Library beginning

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

----- Original Message -----
From: "Guillaume Melquiond" <gmelquio_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Friday, September 06, 2002 1:43 PM
Subject: Re: [boost] Formal Review for Interval Library beginning

> On Fri, 6 Sep 2002, Fernando Cacciola wrote:
>
> > > The problem is not in the user supplying such a mapping. But the user
may
> > > want raw results rather than mapped results.
> > I don't understand what you mean with raw/mapped results.
> > Isn't interval-interval comparisons *always* mapped?
>
> 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.

> 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?
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 <?

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