[std-interval] Comments on the Interval Standard Proposal

Lawrence Crowl Lawrence at Crowl.org
Sun Oct 1 23:28:49 PDT 2006

On 9/30/06, Guillaume Melquiond <guillaume.melquiond at ens-lyon.fr> wrote:
> Le lundi 25 septembre 2006 à 21:27 -0700, Lawrence Crowl a écrit :
> > 26.6.1 Header <interval> synopsis
> >
> >       Might be better to change the namespace from X_ops to X_comparisons?
> >       Such a change is more in line with the actual content.
> The name was inspired by the "rel_ops" STL namespace. I don't have an
> opinion on what a good name would be, especially as it doesn't really
> matter if the name is long since its main use is with "using namespace".

If programmers need two kinds of comparisons in the same function, they
will have to use explicit qualification.

    if ( std::certainly_ops::operator<(a,b) ||
std::possibly_ops::operator>(c,d) )

Under that scenario, I would prefer dropping the '_ops'.  How likely is the

> >    interval(const char *s);
> >
> >       I think undefined behavior here is a very bad idea.  The programmer
> >       cannot effectively avoid the bad behavior without parsing the string
> >       manually.  That is too much of a burden.  I suggest that the parse
> >       either return empty (which is indistinguishable from a successfully
> >       parsed empty) or return an error code, or throw an exception.  You
> >       should ask the library experts for their prefered solution.
> On the contrary, I think undefined behavior is a good idea :). The point
> of this constructor is to define interval constants in the program, e.g.
> ``interval<float> Pi("[3.1415926,3.1415927]");''. With an undefined
> behavior, we may hope that compilers will warn when they detect a syntax
> error, as they already do with printf format strings.
> The constructor was not meant to be used to convert user inputs. The STL
> I/O stream machinery should be used instead as it will correctly detect
> any mistyped input and report it to the program. Am I missing something?

I did not understand the intended use.  For handling literals, I agree that
it is not necessary to have fully defined behavior.  On the other hand, for
literals, the additional cost should be low overall, because all constants
will be defined at namespace scope, and thus amortized to almost nothing.

> >    interval(T lo, T hi);
> >
> >       The undefined behavior here is almost zero cost to avoid.  In particular,
> >       under IEEE 754, the comparison <= returns false when either of its
> >       operands are NaN.  The only cases that fail are interval(-oo,-oo) and
> >       interval(oo,oo).  Assuming that the extra two comparsions to detect
> >       these cases are too expensive, what are the consequences of defining
> >       these two intervals to be valid?  (Remember, I am a language/compiler
> >       person, not an interval person.)
> If you don't manipulate intervals on the extended real numbers, then the
> addition of two intervals [a,b] and [c,d] can be defined as [down(a+c),
> up(b+d)]. So interval addition is just two floating-point additions. By
> using the usual opposite trick, it can even be reduced to one single
> SIMD operation (as this is done in RealLib on SSE2 for example).
> Now let's suppose the interval [-Inf,-Inf] is valid and let's add [0,
> +Inf] with our floating-point additions and IEEE-754 semantic. The
> result is [-Inf,NaN] and this cannot do any good to the rest of the
> program. In order to get a more sensible result like [-Inf,+Inf] (as
> expected in a cset arithmetic for example), you would have to spend a
> lot more time to compute the sum. (There was a proposal to change the
> behavior of floating-point operations in directed rounding mode so that
> they don't generate NaNs, but it wasn't included in 754R).

Okay, I see where the two cases are not good intervals.  Now, are the
extra comparisons for constructing an interval from two floats too

> > On Infinity and NaN.
> >
> >    I think the proposal might be substantially improved by recognizing
> >    two categories of implementation -- those with infinity/NaN values
> >    in their floating-point, and those without.  The second would have
> >    degraded semantics.  The standard probably needs needs a macro
> >    indicating the category.
> I still have a few sentences to fix, but once it is done I expect the
> proposal to be implementable whether infinities and NaNs are supported
> or not. From a programmer point of view, the only difference in behavior
> will be the values returned by the bounds functions "lower", "upper",
> "inf", and "sup" for unbounded and empty intervals. This should be the
> only degraded semantic and, as the proposal stands, it can be tested by
> checking numeric limits. Is this the kind of degraded semantics you were
> speaking about?

Almost, but I think my concerns have been better stated in followups
discussing the representation of unbounded and empty intervals with
explicit fields on those machines that don't have Inf and NaN.

Lawrence Crowl

More information about the Std-interval mailing list