[std-interval] default constructor

[Alan Eliasen]

Guillaume Melquiond wrote:
> Le mercredi 05 avril 2006 à 05:13 -0600, Alan Eliasen a écrit :

>>   I think that there should *never* be a zero-arg default constructor
>>for intervals.  All constructors should have at least one argument to
>>force the programmer to declare their intent. 

> This is too strong a requirement. Forbidding arrays of intervals is a
> sure way of alienating any C++ user. You need a default constructor if
> you don't want the users to go to great and error-prone lengths to
> create arrays (or any higher-level containers).

   Okay, I concede this point, although it is dangerous.

   I would then consider the previous proposal that an interval is
initialized to an "uninitialized" value which causes errors or
propagates itself like NaN if used in a calculation.

   As you may know, there's more than one type of NaN.  There are
"quiet" and "signaling" NaNs.  Quiet NaNs just quietly propagate
themselves in floating-point calculations, like additions or multiplies,
and you'll generally notice them later, but this is incredibly dangerous
if you use them in a boolean expression like:

   if (NaN < 3)
      ...

   or

   if (NaN == NaN)        // (always returns false!)

   Which *doesn't* give you a way of knowing if your calculations were
"poisoned" by this meaningless comparison.

   On the other hand, if you use "signaling" NaNs, attempts at
performing the above comparisons would produce a floating-point error.

   As a result, in a former product, we chose to have switchable NaN
behavior.  In a developer/debug environment, we used signaling NaNs to
find errors of this sort immediately.  We may consider switchable
similar behavior for the Interval standard.  Using an "uninitialized"
interval in a calculation could produce an immediate error or exception.
  This behavior could also be switched off (but I can't think of a good
reason why except it could be faster as a check for uninitialized could
be eliminated.)  I haven't seen nor produced a concrete proposal for
this, but I think it should be considered strongly.

   In fact, the Interval specification could use the above behavior and
initialize itself to NaN (quiet or signaling) to prevent use of
uninitialized Intervals.

   As noted before, simply "poisoning" the results by propagating
uninitialized values isn't enough.  We have to have some way of
indicating errors in boolean comparisons.  What's our proposed policy on
exceptions?

-- 
  Alan Eliasen                 |  "When trouble is solved before it
  eliasen at mindspring.com       |    forms, who calls that clever?"
  http://futureboy.us/         |              --Sun Tzu