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!
>
> Nate,
>
> On the one hand I agree that a global invalid state is an
> inconvenience that may be avoided by Vincent's suggestion.
>
> On the other hand I don't see that the graphics application
> introduces any new aversion to [empty] that you don't
> already have.
>
> After all, if the object is on the screen & visible to
> the 'eye', what homogeneous transformation could possibly
> result in [empty] as an answer?
>
> And, for that matter, if you would rather see NaI as a
> result what are you going to paint on the screen then?
>
> I'll admit that I have not done any graphics in recent
> years so there may have been advancements of which I am
> unaware that would cause this sort of problem. I am
> curious to know what they are.
One day I wish to write a book about it. In the meantime, I fear it will be
difficult in e-mail disucssions to explain everything (and much of it would
be off-topic). Plus many of these ideas as they pertain to computer graphics
are still, unfortunately, confidential.
What I can say as a summary is this:
All of our algorithms use modal interval analysis, so this means {empty}
does not exist in any of our software. Period. One of the reasons we
specifically switched to modal intervals many years ago is because c-set
calculations involving {empty} were giving us problems (see section 8.2 of
my introductory paper for a related topic and example).
In a few cases where we might need to use a classical algorithm like
interval Newton, we just check to see if the Newton step produces an
improper (non-standard) modal interval. If it does, this is proof of
non-existence of the zeros.
Otherwise, NaI is used constructively, as indicator that a special
subroutine or graphics algorithm must be used, for example, or to provide
numerical proof that two interval expressions are not equivalent. It is also
a mechanism that has consistently allowed us to find otherwise very
insiduous bugs in the software during development process.
In future, we plan to advance to massively parallel, SIMD architectures for
modal interval processing of real-time graphics. In that kind of
environment, I just don't believe it will be realistic or practical if the
only way to obtain NaI (or its moral equivalent) is by global/local flags or
traps.
So this is a reason I have some sympathy for Vincent's idea of tagged
intervals, on the one hand. But of course on the other hand I ask all the
questions you put forward about how it affects hardware design, etc.
>> >> 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'm not quite sure of the context here but the invalid state
> is as persistent as an NaI would be. It is just that having
> the invalid (or NaI) tag associated with the interval is much
> the same as having some sort of NaI interval. Again, both
> approaches avoid the global context issue.
The context at this point in discussion was still referring to "invalid"
flag that is not tagged with the interval, but is instead a separate global
or local state that must be checked by user manually or via trap, etc.
>
>>
>>
>>
>>
>> >>> 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...
>>
>> >> . . .
>> >
>>
>> Nate
>
> If by 'typically' you mean in the graphics application you
> don't run across infinities when an object is on the screen,
> then I agree that the typical endpoint will be a finite
> number.
>
> But isn't this all the more reason why differences about how
> we handle things that arise out of infinites (whether they
> come from divide-by-zero's or not) are not relevant to the
> graphics application?
>
> Yours in confusion... :-)
Of course they are all relevant!
Motion 3 was a very good start, in my view, and Motion 5 continues this
trend.
Nate