[std-interval] Draft standard based on csets

[Lawrence Crowl]

On 6/7/06, George Corliss <George.Corliss at marquette.edu> wrote:
> We have prepared a completely revised a draft of a proposed
> standard based on the draft of March 2006 by Br\"onnimann,
> Melquiond, and Pion.

IV.4 : API issues : Internal and external form for intervals

I don't recall that "infty" is a standard form for writing infinities.
I think the C++ standard should not introduce yet another form, as it
make interoperability and shared implementations harder.

26.6 : Interval numbers

Do not use "abstract model" as a short form for "abstract interval model".
There is too great a chance of confusion in the full standard, where
the context is much broader.

26.6.3 paragraph 3 : interval( const char *s )

You must state which exception is raised.

26.6.3 paragraph 6 : interval( const T& lo, const T& hi)

Likewise.

26.6.3 paragraph 7 bullet 3

The functions to specify semi-infinite intervals must be defined.
Alternatively, one could require NaN/infinity support.

26.6.3 paragraph 9

Again, needs to state which exception.

26.6.4 : Interval member operators

All assignment operators should return references to objects,
not values.

26.6.5 : Interval non-member operations

The definition "Returns: interval<T>(lhs) += rhs" is incorrect.
The result of the assignment operator is a reference.  The result
of an addition operator should be an object.  Likewise for the
others.

2.6.6 : Extended division function

Is there a particular reason that you did not define xdiv to
write to non-const reference parameters?  E.g.,

template< typename T >
void xdiv( const interval<T>& dividend, const interval<T>& divisor,
           interval<T>& primary, interval<T>& secondary );

It strikes me that one is likely to want to unpack the pair immediately,
and therefore directly setting variables would be better.

26.6.9 : Interval value operations

I note the potential confusion between "inf" as a floating point value
and an interval operation.  I don't think it is a bit problem, nor
do I have a solution.

26.6.12 : Interval static value operations

Given pi, why not e, etc.?

26.6.13 : External numbers and intervals

The statement "An implementation may provide features beyone the above"
is dangerous.  It grants permission to vendors to claim that non-portable
code is standards-conformant.  Vendors can always add extensions, but
sanctioning them without enumeration is dangerous.  Define what you want
all compilers to conform to and do not mention the rest.  Under that rule,

    [2*pi] requires an expression interpreter in the input library,
    and therefore is difficult to define, annoying to implement, and
    potentially expensive at run time.  So, I would not standardize it.

    [1.1;1.2]e15 is difficult to parse effectively and I would exclude it.

    hexidecimal base numbers are permitted in the C99 standard, and I see
    no particular difficulty in defining them.  Furthermore, they provide
    a means to avoid extending intervals on I/O, and so I recommend putting
    them into the standard.

-- 
Lawrence Crowl