Re: A proposal for the next motion
Vincent Lefevre wrote:
> On 2009-05-18 10:59:01 -0400, Nate Hayes wrote:
>> It does not matter if language defines the scope, since it requires
>> user to do two things:
>>
>> 1. Execute the desired operation
>> 2. Remember to check a status-flag, after the fact
>
> Note that (2) can be done only at the end (if the user wants
> to, as in many applications, the flag can safely be ignored);
> the exception could also be handled in an alternative way (see
> IEEE 754-2008, Section 8), in which case the handler could set
> the result to NaI, and this is exactly what you want.
No! It's exactly what I wish to avoid. Especially in computer graphics
applications, where performance is critical and there is no operation that
can generate {empty} as a result, anyways!
>> This is the situation I don't believe is acceptable. It provides no
>> mechanism or provision to generate a propagating NaI result, i.e.,
>
> The flag is sticky, so that the status is propagated. So, what
> do you mean?
As I mention above, I wish to avoid the situation where a user must put the
flag "back together" with the datatype (and this includes traps).
>>> i.e. an "invalid" flag is attached to the returned interval.
>>> With this choice, the "invalid" flag is set if and only if
>>> you would get NaI with your choice. This just provides more
>>> information.
>>
>> It is interesting idea, but I don't see it is realistic or useful...
>> it is not compatible with existing IEEE 754 data formats,
>
> Any form of interval is not compatible with IEEE 754, since IEEE 754
> deals with numbers, not intervals.
Typically, each endpoint can be an IEEE 754 number...
>> since it requires extra storage.
>
> This may be a problem or not, depending on the application.
>
>> It also does not provide a mechanism for propagating NaI, like
>> mentioned above.
>
> Wrong. Of course, the invalid flag [meaning "possibly invalid"]
> must be propagated.
You're right about that, of course (it must be propagated).
>> Also, it does not generalize to interval functions which may be
>> invalid over parts of the domain, but then may be valid over other
>> disconnected intervals.
>
> What do you mean?
The example you give for tan(-100,100) answers part of my question. But more
specifically, I think about an interval function like:
fR(X) := 1/X \union sqrt(X)
for the interval [-4,4]. In modal thinking, there is no answer (it is
undefined, i.e., "invalid" operation). So fR(X) = NaI. A c-set
interpretation would give something like
(-oo,0) U (0,+oo) U [0,2].
Of course, the 1/X was also invalid at x = 0, and the sqrt(X) was invalid
over [-4,0). So now there are many disconnected items to keep track of. It
could be possible to consolidate all this information into, say
((-oo,+oo),invalid). But in this case lots of valuable information is
destroyed, anyways.
>>> I don't see what you mean: 1/0 is not defined, so is not transformed
>>> into +oo. The IA implementation must take care of these particular
>>> inputs.
>>
>> What I mean is: c-set interpretation (which you advocate as default
>> behavior), transforms, by implication, 1/0 into +oo:
>>
>> 1/[0,3] = [1/3,1/0] = [1/3,1/0=+oo).
>
> No, 1/0 is not +oo. You would need an *unsigned* infinity.
This is part of my point. For example, if I write:
1/[0,3] = [1/3,+oo)
and you are given no further information, it is not possible that you can
tell me if the equation represents the outcome of a c-set operation or if it
is a false mathematical statement.
Nate