more Re: [std-interval] list of functions for intervals

[Guillaume Melquiond]

Le lundi 05 juin 2006 à 12:05 -0500, R. Baker Kearfott a écrit :
> What if, in your example below, R contains two disjoint segments
> of points r such that cos(r) \in R?  Would you return the interval
> hull?

Yes, the result is an interval and it contains all the values matching
the relation, so that the result does not lie. But I don't see this
truth as an issue. Indeed, lots of interval applications tend to split
their domain into sub-domains if the results they have computed are not
precise enough. In that case, they will get to a point where the various
Rs contain only one single contiguous interval.

> In fact, R could possibly contain an arbitrary number of
> such segments.  Thus, acos_rel does give additional utility for
> constraint propagation, but can't give the exact cset in all cases.

Right, but this is a proposal for interval arithmetic, not for arbitrary
set arithmetic. Having acos_rel([0,1], [-inf,inf]) return an infinite
set of implicitly defined intervals is possible but it goes well beyond
what we want to propose here.

And obtaining the "exact" cset is anyway out-of-reach because of bounds
rounding. As a matter of fact, this rounding phenomenon is why I'm not
really fond of cset intervals when they have floating-point bounds (I'm
only speaking for myself here). For example, it means that multiplying
four intervals containing positive and finite numbers can lead to an
interval containing negative values. But I'm digressing.

> Also, I note that Lee's "twin" idea, if I understand it correctly,
> doesn't handle the case with more than two disjoint intervals in the
> cset.  At some point, I'm guessing that we need to accept what
> Lee calls "white lies" in some cases, and design a standard that is
> a good balance between simplicity and utility in a wide variety
> of applications.

Note that Lee's twin idea is fundamentally different from the idea I
presented. First, it only applies to atan2 with respect to trigonometric
functions. For example, there is no meaning in a twin version of acos
since the set extension of acos only returns intervals when it is fed
with intervals. Second, the result of the twin version of atan2 is
constrained to [-Pi,Pi] while cosine and sine on the whole real line.

I'm not saying that the twin idea is a bad idea. As a matter of fact we
have used it for the division in the Boost library, and I still think it
was a good idea. I'm just saying that this is not what people doing
constraints programming are expecting in my opinion. But this could be
useful for other people.

Best regards,

Guillaume