[std-interval] Comments on the Interval Standard Proposal

[Gabriel Dos Reis]

Guillaume Melquiond <guillaume.melquiond at ens-lyon.fr> writes:

[...]

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

A C++ implementation is allowed to emit diagnostics on just about
anything it likes.  The standard text does not have a notion of
"warning", "error".  Rather, it speaks of "diagnostics".  Furthermore,
where the standard requires diagnostics, it does not prohibit an
implementation to accept a program for which a diagnostic is
required -- provided a diagnostic is issued.  See paragraph 8 of
section "1.1 Implementation compliance". 

[...]

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

You should not suggest a standard specification based on the only
optimizations implementations do at the moment.  If you believe GCC
should do more about the comparison optimizations, you should fill a GCC
bugzilla PR.  (and I would refrain from taking GCC as the Gold standard).

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

As I said earlier, I would like to see the number of undefined
behaviour close to zero.  Consequently, either you specify the
operations to deal explicitly with NaNs, or you ban NaN inputs and
therfore make sure that no interval is constructed with NaNs.

-- Gaby