Re: Empty interval representations & Motion 13...
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 (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
--------------------Valid objects----------------+--Invalid 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 invalid ones (ZZ in diagram). Now, I trust implementers to meet the following contract.
- Ensure that every constructed object is valid.
- 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 validity.)
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 valid.
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