[std-interval] Comments on the Interval Standard Proposal

Guillaume Melquiond guillaume.melquiond at ens-lyon.fr
Mon Oct 2 11:06:27 PDT 2006

Le dimanche 01 octobre 2006 à 22:28 -0700, Lawrence Crowl a écrit :

> 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
> scenario.

It may be likely but presumably unneeded, as a "certain" comparison is
the opposite of a "possible" comparison with the current definitions. So
your example can be rewritten as

        using namespace std::certainly_ops;
        if ((a < b) || !(c <= d))

> > 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.
> >
> 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.

I was not concerned with the cost, but with the ability for a compiler
to diagnose a problem: if the behavior is completely defined by the
Standard, then a compile-time warning may be unwarranted. Are there
occurrences in the Standard where a compiler is allowed/suggested to
"warn" (instead of aborting) on some constructs?

> > 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
> expensive?

Actually, there are no extra comparisons, you can write the code so that
all the cases are detected at once. Instead of checking (l <= u), you
just have to check (u - l >= 0) on an IEEE-754 arithmetic with default
behaviors on underflow, overflow, and invalid, but with any rounding
mode (in particular with directed rounding). So it just means one
additional subtraction in constructors.

Obviously, the test also works for single values: (x - x == 0). But now
the cost is non-negligible for arithmetic mixed-type operations, if you
remove the "undefined if not finite" from their definitions. I suppose a
compiler could detect such tests and optimize them away when it knows a
value is finite, e.g. a literal or a midpoint. (I tested with GCC and
-ffinite-math-only, but there are no optimizations of the comparisons,
too bad.)

Now we are back to these two questions. What behavior do we mandate for
constructors on infinities and NaNs? Do we leave some undefinedness so
that libraries can do assumptions on the finiteness of the
floating-point values for mixed-type operations and perform fast
computations? (If not, the behavior would obviously be mandated to be
the same as with constructors.)

Best regards,


More information about the Std-interval mailing list