[std-interval] Mathematical relations and default initialization

[George Corliss]

Sylvain and all,

>>> 1- no default constructor at all
>>> 2- [0,0]
>>> 3- empty
>>> 4- whole
>>> 5- uninitialized tag
>>> 6- see below (something a la "singular iterator")
Could someone fill me in?  I'm not familiar with "singular iterator", and I
found nothing "below" in the original message that helped me understand what
is #6.  Is #6 equivalent to "undefined," in the sense that what you get is
whatever bit pattern happened to be in that memory location from its
previous use?

> (while at it : concerning the propagation of empty, the current
> proposal does not say anything, since any function taking empty
> can return any interval: are there opinions on the sharpness of
> returned intervals in this case?  we could easily enforce empty
> as returned interval)
Ouch!  Yes, that is a (unintended?) consequence of not specifying tightness.

> 6 also has the advantage of speed, I'm thinking especially of array
> initialization.
My understanding of C++ is that happens often, since in some parameter
passing, a default constructor is called and then the appropriate values are
copied into those locations.  Is that close?  Is that why is is a TOTAL
waste of time to initialize an array that is about to be filled anyway?

> I'm not very convinced by the arguments which have been given so
> far in favor of "whole", because I think they mix the correctness
> issue of forgotten initializations, with the preferred value of
> the initializations of variables in *some* algorithms.
> Such algorithms should initialize variables explicitly to "whole",
> IMO.  
No, we agree that it is bad programming practice to rely on default
initializations, no matter what they are.  I am talking about the extent to
which we can protect the careless programmer who forgets to initialize the
variable before using it.

> And given that there is no clear intuitive default, users
> will never remember that "whole" is used as default value, so
> in practice it will be better to use "whole" explicitly anyway
> for these cases, so no need to make it the default constructed
> value.  If somebody thinks it would be too inconvenient to require
> an explicit initialization to "whole" for some codes, I would be
> interesting in seeing such codes.
Does the same argument apply for empty?

I think whole and empty are equivalent in that argument.

Here are two careless programs:

Example 1.
Interval X I think is 1, but it is built with a default constructor that
defaults to empty.
Y = [-1]
Z = HULL (X, Y) 
I think Z encloses all values of sin, but it does not because it is [-1]
I assert that is a containment failure.

Example 2.
Interval X I think is 1, but it is built with a default constructor that
defaults to whole.
Y = [2, 4]
Z = [-3] + set difference Y \ X.
I think Z encloses all values of sin, but it does not because it is empty
I assert that is a containment failure.

Conclusion: NEITHER empty nor whole are immune to containment failure.

I think whole and empty are equivalent in that argument.

Conclusion 2: My case against #6 is pretty weak.

My case favoring whole over empty is not very good, either.


> My personal preference goes to 6 (i.e. producing an "uninitialized
> interval", similar to the behavior of iterators, that is, only
> copies/assignments are allowed on them, basically).
Assuming I have understood what you mean by #6, I am forced to agree.

George