[std-interval] Draft standard based on csets
lawrence.crowl at gmail.com
Fri Jun 9 20:53:51 PDT 2006
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)
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,
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
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.
More information about the Std-interval