[std-interval] Re: winter 2006 draft for standard C++ intervals

[Guillaume Melquiond]

Thanks a lot for your comments.

Le jeudi 02 mars 2006 à 17:09 -0800, Lawrence.Crowl at sun.com a écrit :

> Should intervals be passed by value or by reference?
> 
>    I strongly prefer the pass-by-value approach over the legacy
>    pass-by-reference approach of std::complex.  The choice has
>    implications beyond the efficiency of the interval operations
>    because users will tend to copy the style of the standard.  This
>    pass-by-reference style leads to inefficiency and incorrectness.
> 
>    "Changing [interval parameters from pass-by-reference] to pass by
>    value would only penalize the other ABIs."
> 
>    What evidence do you have to support this claim?

I didn't write this sentence (or at least I don't think so), so I can't
tell what its author meant. But as I understand it, it just means that
an ABI that prefers pass-by-value will not be more penalized than it
already is with std::complex (since both types have the same memory
layout and std::complex is passed by reference), while an ABI that
prefers pass-by-reference will be more penalized than it is with
std::complex when passing by value.

>    "Note that this point is moot when functions are inline, which is
>    expected to be the case most of the time."
> 
>    This statement is entirely untrue for the simple implementations.

By the time interval arithmetic is in the Standard (if it ever is), I
expect the compilers to be able to make this statement holds true, since
inlining is such a strong requirement in C++. But I am perhaps giving
too much credit to compiler writers.

>    This issue is very important.

Agreed. In my opinion, the interval class should indicate (by a typedef
member for example) which parameter-passing convention it uses, so that
it can be left undecided in the Standard. As a consequence, an
implementation would always be optimal yet standardized. No architecture
would be penalized by the passing conventions of its ABI. But I fear
this additional layer of complexity would raise the bar even higher in
order for the proposal to be accepted.

I know some other C++ specialists are subscribed to this mailing-list.
So I would be happy to hear their opinions on a Standard-compliant
parameter-passing convention the interval class should use.

> 26.6 Interval Numbers
> 
>    Paragraph 2 has a stale reference to interval<bool>.

I did some wild cutting in our draft, in order to get this version out
and the ball rolling. So I am not surprised I missed some references to
interval<bool> :-).

> 26.6.1 Header <interval> synopsis // values:
> 
>    Several of the free functions seem more natural to me as member
>    functions.  They are inf, sup, midpoint, and width.

There is an inconvenience with such member functions: you can't use them
in template algorithms that expects a "UnaryFunction" argument. This is
one of the concepts of the STL and the C++ language cannot use member
functions in these places unfortunately. By providing these functions as
free functions, the user can for example type

  std::transform(vec1.begin(), vec1.end(), vec2.begin(), midpoint);

in order to compute the vector of midpoints of a vector of intervals.

> 26.6.1 Header <interval> synopsis // set operations:
> 
>    These operations seem much more natural to me as member functions.
>    Consider:
> 
>       if ( contains( a, b ) )
> 
>    versus
> 
>       if ( a.contains(b) )

Agreed, the member function syntax is nicer. But for the same reason as
before, this prevents "contains" from being directly used with
algorithms that expect "BinaryFunction" or "BinaryPredicate" arguments.

>    or more signficiantly
> 
>       a = intersect( hull( a, b ), c );
> 
>    versus
> 
>       a = a.hull(b).intersect(c);

On the previous examples, I agree that the member function syntax looked
nicer and more natural. But on this example I disagree. Such a syntax is
tied to a different semantic in my opinion. If I read "a.hull(b)", I
expect the interval stored in "a" to be modified by adding "b". The
syntax is too close from "a += b" to have the semantic of "a + b".

> 26.6.11 interval static value operations
> 
>    Based on the example in VI.1, you also need
> 
>       interval<T> interval<T>::epsilon()
>          { return interval( -std::numeric_limits<T>::min(), 
>                              std::numeric_limits<T>::min() ); }

I suppose this one could be mathematically defined as the tightest
representable interval such that it contains zero yet zero is not a
bound. Is epsilon a suitable name?

>    And based on the example in VI.2, you also need
> 
>       interval<T> interval<T>::min()
>          { return interval( std::numeric_limits<T>::min(), 
>                             std::numeric_limits<T>::min() ); }

I cannot find a concise mathematical definition for this interval. Are
there practical uses for it?

On this subject, are there other interval constants that people feel
useful?

Best regards,

Guillaume