Re: A proposal for the next motion
> Nate,
>
> I'm sure that quadratic surfaces & reflections both specular &
> otherwise present you with non-linear processes. I'm not sure
> I would characterize them as 'exotic' but that's neither here
> nor there.
This view of computer graphics is too simple, especially when intervals are
added to the picture (no pun intended). For example, see
- Snyder, John. “Generative Modeling for Computer Graphics and CAD:
Symbolic Shape Design Using Interval Analysis.” Academic Press, 1992
which uses CAS-like metalanguage and toolbox of nonlinear optimization
solvers, or
- Heidrich, Wolfgang and Hans-Peter Seidel. “Ray-tracing Procedural
Displacement Shaders.” Graphics Interface, 1998
which explores some problems encountered when rendering discontinuous
surfaces (see Chapter 5, in particular, which uses a tagged interval
concept similar to the ideas mentioned in this thread). These references are
outdated and barely scratch the surface. But they provide better context.
> I'm also sure you know things about this field that are far
> beyond the ken of the rest of us.
>
> Still I would like to see some simple example that us mere
> mortals can understand. Some image of the princess that cannot
> be rendered without NaIs. I'd like you to point to some soft
> curve that produces an NaI that allows you to render it in a
> way that [empty] or {[empty], NaI} would ruin the image for the
> eye. Or perhaps the reflection of the tip of a sword off the
> brass armor brestplate that would otherwise appear unreal.
>
> Anything along these lines.
>
> If you say it is so I will believe you. But merely saying it is
> so provides me with no understanding of why. Or how.
I mentioned earlier these particular topics are confidential. So I can't
give details on our use of NaI, or the Sunfish police will come and take me
away.
We can have discussion and understanding by limiting ourselves to other
examples. I have given some in my paper, as well as in my last e-mail. If
you take a closer look, I think you'll see there's something useful and
constructive which can be learned from them.
>
> This example is no more compelling for its repetition. And your
Perhaps you don't find it "compelling," but it is also not untrue.
> In the end it may be that this is a religious issue similar to
> what is your favorite computer language, text editor, or
> operating system.
Maybe for you or others it is "religious" issue. To me, I just look at what
does the mathematics say is true (this is the predicate-based approach to
constructing sets of real numbers by Gardenes, et. al.). It is a logical and
valid way to look at things that has long history and tradition.
In any case, you already accept NaI in principle, since you advocate that
intervals are tagged with "invalid" flag. At application level I agree it
works, but don't see yet anyone provides realistic evidence hardware vendors
will change registers and busses just to conform this idea. Only other
option is to separate the flag from the interval and then require the user
must "put it back together" via traps or something, but you also agree this
is bad idea.
So a good solution is to support two operations:
op1: sqrt([-1,4]) = NaI
op2: sqrt([-1,4]) = [0,2]
In both cases, a separated "invalid" global/local flag can still be set.
Then Jurgen's expression templates can easily allow user at application
level to specify any of the following options:
1. Propagate only the NaI result.
2. Propagate only the c-set.
3. Progagate the c-set and the "invalid" flag.
Of course, most typical c-set users will choose option 2, and most typical
modal interval users will choose option 1. Both can be implemented entirely
in existing hardware registers and busses with no software support. Some
special hybrid applications may wish to choose option 3, but only in this
case will users have to suffer the issues associated with traps.
> It would be nice if we could remove all such issues from the
> standard in a sort of intervals separation of church & state.
> I know the IEEE would like us to do this on grounds of not
> favoring any existing vendor. But I fear it will not be the
> case.
I don't see censorship would be in spirit of IEEE... it is a poor way to win
an argument or majority.
Nate