[std-interval] Initialization

[first.i.last at comcast.net]

There's an attribution missing in the original.

> Message: 1
> Date: Tue, 04 Apr 2006 20:57:00 -0500
> From: George Corliss <George.Corliss at marquette.edu>
> Subject: Re: [std-interval] C++ interval std
> To: For discussions concerning the C++ standardization of intervals
> 	<std-interval at compgeom.poly.edu>
> Message-ID: <C0588E1C.38EC%George.Corliss at Marquette.edu>
> Content-Type: text/plain;	charset="US-ASCII"
> 
> Sylvain Pion wrote:

> >> Uninitialized.  The convention in C/C++ is to initialize to zero,
> >> but we agree that is not correct for intervals.  Whole is probably
> >> the best we can do.
> > 
> > I'm not convinced.  Initilization to [0,0] seems nice to me for
> > intervals because of homogeneity reasons with floating-point.
> > I could even imagine that the empty interval would make as much
> > sense as whole.
> > 
> > What makes you think that [0,0] is "not correct", and why 'whole'
> > would be better than 'empty' ?
> I agree that initialization of uninitialized intervals to [0,0] is easy, and
> it is consistent with floating-point practice.

Not always true.   For dynamic creation on the stack or heap there is no such promise.  For static initialization the promise is _not_ initialization to the value zero, but to the bitpattern all bits off, which may or may not produce a value of zero..

>  My reservation is that it can lead to violations of containment.
> 
> The issue is not with "our" code.  It is with users' code.  Floating-point
> arithmetic makes no promises of accuracy.  Intervals promise a guaranteed
> enclosure.  If a user mis-uses our tools and gets a violation of
> containment, WE will be blamed, not the programmer who forgot to initialize
> all variables.  I want to make it as difficult as possible for even
> incorrect code to lie.
> 
> Simple example:
>    interval Pi;
>    cout << "Pi is enclosed by " << Pi;
> 
> The result violates containment if the default initializer is either [0, 0]
> or Empty.  It is truthful if the initializer is Whole.

I find that to be just as misleading.  The problem is that the variable is named in a misleading manner.  If you use a more descriptive name you will not be mislead:

    interval Uninitialized;
    cout << "Pi is enclosed by " <<Uninitialized";

This puts the problem out of the domain of the standard and squarely on the back of the quality of the implementation of the application software.

For a case where the whole number line is a lie consider:

    cout << "e^(i*pi) is enclosed by " << whole();
> 
> Of course, no one would do that on purpose, but programmers DO sometimes use
> variables they have not initialized.

That's not the problem of the standard.  When there is a choice between minimizing user errors at the cost of hiding some of them versus indicating user errors at the cost of convenience, the choice should always be the latter because the former is unacceptable.

> 
> One easy-to-imagine case might define a variable by a complicated set of
> nested cases/ifs.  The programmer thinks all possible cases are covered, but
> misses one case.  In that case, the variable is not given a value, but the
> following code uses it, unaware that it might not have been assigned a valid
> value.

That is not something you fix by providing an initialization that is magically correct in all cases.  That is something you fix by creating an unambiguous indication that a variable has been used without being initialized.  Note that there have been software tools to do this for a long time.  In fact many compilers now perform this check automatically.  It is not always possible to detect at compile time, so a run-time flag/state/value is called for.

There is a strong concensus within the software engineering community that what used to be known as defensive programming hides errors.  The modern practice is to prefer exaggerations of errors over exaggerations of correctness.

Taken to the limit (reductio) the standard would have to forbid this
    interval target = 0;
    memset( &target, 0 );


> 
> Asserting that a set is empty is perhaps the strongest assertion one can
> make about a set.  Asserting that it is contained in the universal set is
> the weakest assertion one can make.  That is why I argue for Whole.

Whole is not the universal set.  Whole asserts that the value is a number.  But an uninitialized variable does not contain a number.

> 
> I'd like to have some special "undefined" value that would propagate like a
> NaN, but that is too much to ask for.

Why is it too much?  On IEEE platforms NaN is easily available.  And the standard already has a definition of a special (bad) numeric value for other platforms.  The proposal should at least include the provisions parallel to those already supported by the standard.

>  Whole does not lie.

There are cases where it does lie.  And in the cases where it does not lie it certainly hides software defects.

------------------------------

> Message: 4
> Date: Wed, 05 Apr 2006 05:13:15 -0600
> From: Alan Eliasen <eliasen at mindspring.com>
> Subject: Re: [std-interval] Re: Std-interval Digest, Vol 3, Issue 1
> To: For discussions concerning the C++ standardization of intervals
> 	<std-interval at compgeom.poly.edu>
> Message-ID: <4433A64B.4000708 at mindspring.com>
> Content-Type: text/plain; charset=us-ascii
> 
> first.i.last at comcast.net wrote:
> >>but we agree that is not correct for intervals.  Whole is probably
> >>the best we can do.
> > 
> > Yuck.  Empty is clearly superior to whole in that it has less 
> > chance of accidentally producing apparently sensible results.
> > And for production an uninitialized interval should not be
> > initialized.  After all,  C++ lacks basis support for array
> > initialization so any default initialization effort, like touching
> > every value in a big array, is just wasted time.
> 
>    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.  There's no point to a
> zero-argument constructor, because allowing such gives the programmer
> *lots* of ways to mess up and use uninitialized objects.  If you want to
> use an interval, you should provide reasonable arguments to it in a
> constructor.  That way, you *never* get an Interval object that hasn't
> been initialized to a known value.  A huge class of errors is eliminated
> at compile-time!
> 
>    In my interval implementations in Java, there's no way to construct
> an interval without specifying its values.  There's no reason to allow a
> "default" interval.  I believe in constructing APIs that eliminate
> sources of expected programmer error at compile-time.  This is an
> obvious case.
> 
>    There is simply no reason to allow a "default" interval initialized
> to a value that we *know* isn't right for anything.  We can prevent this
> mess at compile time, and should.

The reaction of a practicing software engineer to the above suggestion is to get out his garlic and silver crucifix and back away slowly sreaming CHANGE IN SCOPE!

Is the goal to incrementally add intervals to C++ as a kind of monotonic action or is there a willingness to force changes in the basic architecture of the language?

1. Some standard containers require default ctors.
2. Dynamic arrays (but not static arrays) require default ctors.
3. We should not make correctness promises for intervals that exceed the promises that:
    a. we can keep
           Uninitialized intervals would still exist because the user can:
                      interval * p = (interval *) malloc(100);
    b. already exist the language for similar types
           No matter what the standard says users are going to treat intervals as alternative
           forms of floating point.  So we should minimize the variations with existing C++
           numeric practice in both positive and negative directions.

The best way to get this issue into the standard is to propose that the standard recommend but not require a diagnostic.

=============================================

-- Lee Winter