[std-interval] Re:proposed C++ Interval standard

[Guillaume Melquiond]

Le mercredi 13 septembre 2006 à 12:28 +0200, Jean-Pierre Merlet a
écrit :
> Nice job by Herve, Guillaume and Sylvain.

Thanks.

> I have two questions:
> 
> -should not be some definition about the returned enclosure of inverse 
> functions such as:
> 2 Returns: an enclosure of {acos(x) | x in X and x in [ 1,1]}. template 
> < class T> interval <T> acosh ( interval <T> X);
> Should we impose that the enclosure be include in the range [0,pi] ?

In the current draft, this is left as a matter of quality of
implementation. Due to Pi not being representable by a floating-point
matter, writing a specification is not simple. Let's name Pi+ the first
floating-point number after Pi.

The floating-point enclosure of acos([-1,-1]) has to contain Pi+, so we
are necessarily outside the mathematical range [0,Pi]. Due to the
mathematical properties of acos, we could still avoid this problem by
saying: unless the input interval contains -1, the output interval has
to be included in the mathematical range [0,Pi].

The problem becomes, however, more difficult for the atan function. A
lot of floating-point bounds require the output interval to contain Pi
+/2 and/or its opposite. So we can't have a simple specification that
requires the output to be included in [-Pi/2,Pi/2].

Now we could write a specification that simply requires the output
interval to be included in [-Pi+/2,Pi+/2]. I don't really see the point
of such a specification, as it allows for values outside the
mathematical range. It the user algorithm supports a bound like Pi+/2,
but not the next few floating-point numbers, then it should simply
perform an interval intersection to remove these values.

As a consequence, I would say that there is no need to impose more than
this design decision: "the standard should not require implementations
to return the sharpest intervals possible, but only preserve the
containment property for all functions."

> -you are not talking about interval vectors and matrices except in VI.2.
> where you are using is[s], s being the index, starting at s=0. This will 
> not be compatible with PROFIL notations using is(s) with s starting at 
> 1. I am not that familiar with C++ but I guess we may template another 
> vector definition compatible with PROFIL while still using the C++ 
> standard ?

This question is easier to answer. Section VI.2 contains an example that
relies on features that have existed since the first standardization of
C++, namely std::vector. C++ provides three kinds of vector/matrix
structures: classical C arrays, std::vector, and std::valarray. They can
all be used with an interval value type, and they all use the square
brackets and start at index 0. If the C++ standard ever describes a
generic linear algebra library, I'm quite sure it will rely on the same
syntax. So, with the array syntax you describe, PROFIL is quite off from
C++ practice in my opinion.

But this is actually irrelevant. Our proposal only describes the basic
interval type. If we start to define vector and matrix types, we will
have to define arithmetic operators on them, and so on. This is out of
the scope of our proposal. An additional proposal could be written
afterwards (though I think C++ developers would be a lot more receptive
to a generic linear algebra library rather than a specific interval
linear algebra library).

Best regards,

Guillaume