[std-interval] Mathematical relations and default initialization
Sylvain.Pion at sophia.inria.fr
Sun Oct 1 15:19:07 PDT 2006
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
>> 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
>> 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
>> 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
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.
More information about the Std-interval