[std-interval] Comments on the Interval Standard Proposal

[Guillaume Melquiond]

Le dimanche 01 octobre 2006 à 17:41 +0200, Gabriel Dos Reis a écrit :

> | 2. From a library point of view, missing IEEE-754 infinities make the
> | code a bit more complicated and a lot slower, as you need to detect
> | overflows by hand. Representation doesn't even require extra data
> | members, as half of the data space is left unused by proper intervals,
> | so you can store unbounded intervals by using reversed bounds.
> 
> For implementations lacking IEEE-754, LIA-1 semantics is that if an
> operation is to overflow then it should raise an exception.  So, your
> specification has to explicilty take that into account saying whether
> the library functions are allowed to raise exceptions or not.

I don't understand. Overflow does not mean anything for an interval
function. If an implementation wants to use internal operations that may
throw an exception, then it just has to catch it and deal with it.
Whatever the implementation, it should respect the interface mandated by
the standard and be transparent for the user. Are you suggesting that we
add a "throw()" exception specification to most interval functions so
that this expected behavior is clear?

> | 3. From a user point of view, missing infinities give unexpected results
> | for the value access functions when dealing with unbounded intervals.
> 
> If you hook the interval library on LIA-1, then this aspect is
> something to be described because LIA-1 does nto mandate infinities.
> Instead, it mandates exceptions.

I don't hook the interval library to anything. There are no expectation
on the presence or not of infinities in the proposal, as all the
references to them are protected by std::numeric_limits<T>::
has_infinity. The only function with an unclear behavior is the "width"
function, as even a bounded interval may be large enough to have an
unrepresentable width. I'm not really sure what a correct behavior would
be here. A possibility could be to forget about "width" and propose
"radius" instead, as this function would return a finite value for a
bounded interval.

Best regards,

Guillaume