Re: A proposal for the next motion
> Date: Thu, 21 May 2009 10:04:45 -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.
>
>
>
> >> 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.
>
>
>
>
> >>> 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... :-)
Dan