[std-interval] Mathematical relations and default initialization
Sylvain Pion
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
>
> 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
More information about the Std-interval
mailing list