[std-interval] Mathematical relations and default initialization

[Sylvain Pion]

John, sorry for coming back 2 weeks after your mail,
I have been busy with administrative stuff lately.

Dr John Pryce a écrit :
> Sylvain, George and all
> 
> Re:
>> 1- no default constructor at all
>> 2- [0,0]
>> 3- empty
>> 4- whole
>> 5- uninitialized tag
>> 6- see below (something a la "singular iterator")
> 
> At 10:08 15/09/06, Sylvain Pion wrote:
>> George Corliss wrote:
>>> ... 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?
>>
>> It [allows] the behavior you mention, but also many others...
>>
>> The specification for #6 could look like the following.
>> " An interval object is always in one of the two following exclusive
>> states: initialized or uninitialized. The default constructor produces
>> uninitialized intervals. The state is propagated through assignments
>> and copy constructors. The other constructors produce initialized
>> intervals. Other operations on uninitialized intervals have undefined
>> behavior, while operations on initialized intervals follow the semantic
>> described in this chapter. "
> 
> Now you spell out the semantics so clearly, I begin to like #6. If it is 
> policy that every interval operation HAS TO return an interval (and I 
> don't mean just an object of interval type, I mean a member of the 
> abstract interval model, i.e. a set) then I still favour "whole" over 
> "empty" - George, I comment below on your examples.
> 
> But I sense a general view that this is NOT good policy. There are 
> operation-instances where it is certain or extremely probable that the 
> programmer has overlooked something, and there is no sensible way to 
> continue the computation. "x = interval<double>(NaN,3);" for instance. I 
> have argued for throwing an exception in such a case. But I accept the 
> force of the argument that this also is bad policy in the case of large 
> parallel computations. Assume we have made the constructor work 
> elementwise for arrays, and we have
>     x = interval<double>(xlo,xhi);
> where x,xlo,xhi are arrays of a million elements. If just one element of 
> x failed to be constructed because of a NaN in xlo or xhi, we would like 
> to continue working with the "good" 999999 while STILL BEING ABLE to 
> detect that the computation with the one bad value produces garbage output.
> 
> Sylvain, your specification of #6 looks very like one for "Not an 
> Interval", NaI: just as NaN is a floating-point object that does not 
> represent a value in the abstract model of (extended-)real numbers, so 
> NaI is an interval object that does not represent a value in the 
> abstract model of (extended-)real intervals. Is that a fair description?

As Lawrence said, it is not an NaI because it is not something that
concretely exists: you cannot test for it; the uninitialized interval
also does not propagate like NaNs through operations since operations
on it are undefined.  The goals are :
- allow the fastest possible implementation (which just leaves what
   is in memory, even if it's not a valid interval value).
- allow a "debug mode" which identifies uses of uninitialized intervals
   (at compile time as Lawrence mentioned, but also run-time)


Since there seems to be consensus about this question, I will commit
the description above in the proposal.


>>>> (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.
>>
>> If there is consensus on that, then we can add the enforced propagation
>> of empty intervals... I guess that the typical efficient 
>> representation of empty (with NaNs) will propagate at no additional 
>> cost...
>> On the other hand, I'm not sure it's very useful to
>> specify propagation of empty ...
>> Not specifying tightness at all is easy, but it is also risky: it allows
>> a dumb ("return whole") implementation, be standard compliant.
> 
> Is it "risky"? There are enough good interval systems out there for 
> market forces to weed out the shoddy ones or force them to improve. Or 
> am I naive?

Well, past experience with C++98 shows that compiler vendors have
priorities...
And I don't see intervals as being the top-priority of the majority
of customers to put pressure on vendors, so they might be tempted to
implement a dumb thing just to claim standard compliance quickly.

That said, I may be paranoid.
I also like the arguments you mentioned of specifying constraints
which can be useful for some applications, when they don't cost much.
Their precise identification is not easy, though.

-- 
Sylvain