Re: A proposal for the next motion
> Date: Mon, 18 May 2009 16:04:41 -0400
> From: Nate Hayes <nh@xxxxxxxxxxxxxxxxx>
> Subject: Re: A proposal for the next motion
> To: STDS-1788@xxxxxxxxxxxxxxxxx
>
> Hi Dan,
>
> Thanks for the clarification.
>
> Without copy of 754-2008, its difficult for me to be precise with those new
> terms. So I'll avoid them for now.
>
> Bottom line, I think the user needs to be able to choose
>
> sqrt([-4,-1]) = NaI or sqrt([-4,-1]) = {empty}
>
> at the time they invoke the function. Requiring this decision to be made
> before-hand via setting of some flag is not a good idea (it conjures all the
> pain interval practioners currently deal with regarding changing of rounding
> modes). Also, requiring user to
>
> 1. Perform the operation sqrt([-4,-1]) = {empty}
> 2. Check status flag after the fact to see if it was NaI
>
> is another scenario to be avoided, in my view. It is not practical (or safe)
> to design a modal interval processor which must conform to this idea.
>
> In our own modal processor, it would be practical, easy and safe for us to
> support two op-codes:
>
> op1: sqrt([-4,-1]) = NaI
> op2: sqrt([-4,-1]) = {empty}.
>
> Alternatively, it could be just one op-code with an immediate-mode flag to
> control the outcome, not unlike the SHUFPD SSE2 instruction, for example.
> Whatever is the correct terminology for this idea I will leave up to others.
> But I hope this is clear enough picture to make the point.
>
> Another acceptable option, from my perspective, is to always make
>
> sqrt([-4,-1]) = NaI
>
> because it is the most fundamental and conservative interpretation. But this
> requires c-set users to explicitly intersect input arguments with the
> natural domain of the function (as discussed in my recent e-mails with
> Vincent). I still don't think this is unrealistic option. But if people
> object, then the two-opcode solution above is the best alternative (and I
> would support it).
>
> My general concern is there appears to be lots of effort to avoid NaI
> altogether. But the truth is, NaI is the best and most appropriate result
> for some lines of mathematical thinking.
>
> Nate
>
Nate,
You're not thinking through what Vincent is proposing.
First, I think we can all agree that a control flag to choose
between NaI's & c-sets is a bad idea. With Vincent's approach
it is not needed. There is also no need for 2 'opcodes'. (You
should know that we won't be defining things like instruction
decoding anyway.)
Second, your objection to checking some status information to
see if an NaI has been created is vacuous. After all, even if
an NaI was returned you would still have to check for it with
some predicate of the form isNaI(xx). You will still have that
predicate. It will just look at different bits to get its
answer. With Vincent's way you could even have an 'NaI' tag bit
if you like.
Third, I claim Vincent's approach is IDENTICAL to returning an
NaI for those that want it. The information is recorded along
with the c-set result. That information is never lost. And it
is testable in the same way as if it had been returned in the
interval. The only difference is that the c-set people can be
made happy as well in that the c-set result can ALSO be placed
in the resulting interval.
(It is also identical to returning c-sets to those who won't
bother with the tag bits but I'm sure that is of little interest
to you.)
As for issues of "fundamental and conservative", that seems to
be in the eye of the beholder & the c-set people seem to have
grabbed this particular elephant in a different place than you.
I think the prudent thing for both of you is to wash your hands
& consider grabbing the beast somewhere else. :-)
After all, the way you are going one of you will be unhappy.
With Vincent's approach you may each view intervals as if they
were done in just your way all the while in blissful ignorance
that the others are also smiling.
Its worth considering...
Dan
P.S. - As for avoiding NaI altogether, you are correct that it
is something I think might be useful. With the hindsight of
the past quarter century I would have to say that NaNs have been
more trouble than they are worth. I'm not sure we will succeed
in avoiding the moral equivalent for intervals but it seems to
be worth the attempt. Especially if the "best and most
appropriate result" is also there in the form of an 'NaI' tag.