Re: A proposal for the next motion
> Date: Thu, 21 May 2009 17:35:12 -0400
> From: Nate Hayes <nh@xxxxxxxxxxxxxxxxx>
> Subject: Re: A proposal for the next motion
> To: STDS-1788@xxxxxxxxxxxxxxxxx
>
> >> 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).
Actually my question is how either [empty] or NaI would arise
in graphics applications involving the rendering of real scenes.
>
> 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.
This would seem to be the equivalent of proving the non-existence
of zeros in an interval that gets contracted to the empty set.
Is it not?
>
> 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.
Now this is different. If you are INTRODUCING NaI's as some
sort of programming indicator then I guess they cannot be
avoided. Unless, of course, Vincent's tags included some
sort of 'programming hack' tag as well. Its possible I
suppose.
BTW, your programming trick is similar to the two examples of
practical uses for signalling NaNs that were brought to us at
754 when we tried to get rid of sNaNs for performance reasons
among others. Prof Kahan & I published an article in Computer
Magazine asking the world for sNaN uses & we got only these two.
Of these two, one was old enough that the sources no longer
existed & the other was an extensible interpretive language
that could solve the problem in another way.
Perhaps some reflection will show that you can solve your
problem in some other way as well.
>
> 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.
Agreed. Let's just eliminate this notion from the discussion.
>
> 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.
>
> . . .
>
> Nate
There is one other I realized after I posted my list: There is
the issue of register space for them mirroring the registers
used to hold the interval bounds. Whether registers otherwise
holding floating-point values are overloaded for this purpose or
new register space (& busses) are created specifically for this
task, the cost is non-trivial.
That's for some sort of full-blown interval implementation
though. Some more tepid form of interval support through a
mixture of special floating-point instructions & tag management
instructions could be had for not much more than the opcode
space to put them there. In this case the performance would
be similar to the best floating-point performance but without
all the case analysis that dogs many of today's implementations.
It is a compromise that might be able to be sold to chip
manufacturers that are otherwise dubious of their customers'
need for fast interval support.
Enjoy,
Dan