Re: A proposal for the next motion
Dear Dan,
I don't argue at all the points you make about Vincent's idea. Clearly they
are true. Whether it is practical or realistic to expect hardware vendors to
support that idea is another question. I can see at the language or
application level that model may work very well, particularly in CAS like
Mathematica or something.
If you and Vincent are serious, why don't you write a paper or proposal.
That way we can see the details of how it is supposed to work. Especially if
you could address the concerns I raise in my previous e-mail to Vincent, I
would take a closer look.
Best,
Nate
----- Original Message -----
From: "Dan Zuras Intervals" <intervals08@xxxxxxxxxxxxxx>
To: "Nate Hayes" <nh@xxxxxxxxxxxxxxxxx>
Cc: <STDS-1788@xxxxxxxxxxxxxxxxx>; "Dan Zuras Intervals"
<intervals08@xxxxxxxxxxxxxx>
Sent: Monday, May 18, 2009 7:48 PM
Subject: 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.