Re: Empty interval representations & Motion 13...
<I noticed that I had used "(in)valid" in two senses: (a) of a level 2 datum, as meaning "decorated interval whose 'valid' property has a certain value", (b) of a level 3 object, meaning "representing a level 2 datum, or not doing so". I have changed it to use "well-formed" and "ill-formed" for the level 3 meaning. Please discard the previous version.>
P1788, Dan, Jürgen
On 22 Apr 2010, at 17:17, Jürgen Wolff von Gudenberg wrote:
> Dan
> your representation may simplify comparisons but on the other hand
> it complicates arithmetic.
> Juergen
>
> Dan Zuras Intervals schrieb:
>> I have been thinking about something for some time now
>> & Ulrich's recent revision of Motion 13 has brought it
>> up again.
>> It is the issue of the representation of the empty
>> interval.
>> Many of you out there seem to presume that the proper
>> representation for the empty interval is [NaN,NaN].
>> And this may turn out to be the best thing for us.
>> But let me point out that we have scrupulously avoided
>> NaNs in any form at all so far.
>> And I believe this is a good thing.
>> NaNs cause trouble where ever they appear. They even
>> cause trouble when they MIGHT appear. At the very least,
>> the diligent function writer must take into account the
>> possibility that it might happen somewhere in his code.
This makes me realise there is a defect of the statement in 6.1 of the text:
"An implementation may choose any means to represent a level 2 interval datum x, provided that it shall be possible to retrieve the bounds of x exactly."
It should say, I think,
"An implementation may choose any means to represent a level 2 interval datum xx, provided that it shall be possible to retrieve the bounds of *each nonempty* xx exactly."
The bounds inf(), sup() of any other datum are neither here nor there:
- Mathematical convention, at least in analysis, usually takes those of xx=Empty to be inf(xx)=+oo, sup(xx)=-oo.
- The bounds of any invalid interval datum (they are all indistinguishable, so I increasingly think they/it is just NaI under another name) must be returned as some floating point datum; the only sensible value is NaN.
Dan, what is worrying you? NaN doesn't exist at level 2. Here's a diagram, for the case of binary operations.
level 2 datums xx1, xx2 xx1 op xx2 = yy + ???
| ^ + ^
v | + |
level 3 objects XX1, XX2 XX1 OP XX2 = YY + ZZ
-------------Well-formed objects----------------+--Ill-formed objects--
where the downward map is
XX = repOf(xx) = object that represents xx (one to many, and not onto)
and the upward map is
yy = repdBy(YY) = datum represented by YY" (many to one, i.e. a function, and onto).
There is also "OP = implementation of op".
Some objects don't represent any datum -- the ill-formed ones (ZZ in diagram). Now, I trust implementers to meet the following contract.
- Ensure that every constructed object is well-formed,
i.e. is a representation of some datum.
- Make each OP a correct implementation of its op,
i.e. ensure that the above diagram commutes.
(Questions of accuracy mode come in, but do not
affect well-formed-ness.)
Since yy is a datum, for any input datums xx1 and xx2, it then follows that YY must be a representation of yy, hence YY is well-formed.
If any ZZ's occur it can *only* come from "beyond the model" events, such as storage corruption or use of illicit machine-code routines, etc.
Whether NaN may be a possible value of a field in a level 3 object neither increases or decreases the risk of what Dan calls "trouble". I don't think we should impose on implementers any particular representation of things like the empty set.
John