Re: A proposal for the next motion
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
----- 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 11:05 AM
Subject: Re: A proposal for the next motion
>> Date: Sun, 17 May 2009 22:34:39 -0400
>> From: Nate Hayes <nh@xxxxxxxxxxxxxxxxx>
>> Subject: Re: A proposal for the next motion
>> To: STDS-1788@xxxxxxxxxxxxxxxxx
>>
>> Vincent Lefevre wrote:
>> > Dear Nate,
>> >
>> > On 2009-05-13 20:47:53 -0400, Nate Hayes wrote:
>> >> Dear Vincent,
>> >>
>> >>> Vincent Lefevre wrote:
>> >>> On 2009-05-13 18:23:30 -0400, Nate Hayes wrote:
>> >>>> Global flags are technology from the 70's and don't work well in
>> >>>> modern multi-core, multi-threaded computing environments.
>> >>>
>> >>> . . .
>>
>> My understanding is IEEE 754-2008 attempts to stop speaking of global
>> flags and instead speak of "attributes". For example, a conforming
>> application could provide four op-codes for addition, one each with a
>> different hard-wired rounding mode. This is not unlike the examples in
>> Ulrich's letters to the IEEE.
>>
>> It is a more modern concept, i.e., "attribute" (I think I also heard
>> Michel
>> refer to this idea as "local flag"). The main idea is there is nothing
>> that
>> requires it to be global, like the rounding-mode control flags on current
>> x87 FPUs, for example (which can flush the pipeline and give processor
>> stalls when you change them).
>>
>> I don't actually have a copy of IEEE 754-2008 yet, so I'll let Dan or
>> Michel
>> correct me if I misrepresent this idea.
>>
>> . . .
>>
>> Nate
>
> Nate,
>
> Vincent has it correct with attributes as modes. In a sense,
> Michel does as well but attributes as flags is a bit misleading.
>
> "Attributes" (nee modes) are the subject of Clause 4: Attributes
> and Rounding. And we tried to make it clear that they can have
> a local scope. This covers what used to be called rounding
> modes as well as exeption modes.
>
> But "flags" are the subject of Clause 7: Default Exception
> Handling & Clause 8: Alternate Exception Handling Attributes.
>
> In Clause 7 the use of 'flags' is much the same as in 754-1985
> but as have tried to make the distinction between 'exception'
> (the thing that caused the trouble) & 'flag' (the place it was
> recorded).
>
> In Clause 8 the word 'attributes' is used in an attempt to apply
> scope to exceptional results.
>
> But Clause 8 is, unfortunately, optional. So we can't count on
> it to be there even if we were limiting ourselves to a 754-2008
> environment (which it seems we are not doing).
>
> Still, we can require more of an implementation than the minimum
> of 754-2008. So if you think its important we could specify
> that they implement the option of Clause 8. But if we couldn't
> get restriction to 754-2008 to pass I doubt we could get that to
> pass. IMHO, of course.
>
> BTW, get your copy of 754-2008. You may find that some of your
> problems with modals can be attacked by things in there. My
> reply to Vincent's previous post should give a hint.
>
> Take care,
>
> Dan