Re: A proposal for the next motion
Dear Vincent,
> On 2009-05-17 22:34:39 -0400, Nate Hayes wrote:
>> Vincent Lefevre wrote:
>>> There are (global) flags in IEEE 754-2008. Their scope is
>>> language-defined.
>>
>> 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.
>
> I was not speaking of "attributes" (called "modes" in the old
> IEEE 754-1985 standard), but what IEEE 754-2008 calls "flags"
> or "status flags", e.g. in 7.1:
>
> 7.1 Overview: exceptions and flags
>
> What's important is that flags are not attached to each result
> but have some "global" form (I'm not sure of the right word to
> mean that something is not attached to the result and affects
> the environment). Then, what "global" really means, i.e. what
> the scope is, depends on the implementation (this is typically
> defined by the language).
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
This is the situation I don't believe is acceptable. It provides no
mechanism or provision to generate a propagating NaI result, i.e.,
sqrt([-4,-1]) = NaI,
which is the best answer if user is not interested in c-set convention.
So for these reasons, I think the "attribute" approach which can then be
easily implemented as two op-codes (or a single op-code with immediate-mode
flag) is much better solution.
>> 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).
>
> This may be true for attributes, but AFAIK, not for the flags.
>
> Also, concerning these rounding modes, that's an implementation
> choice. In particular, IEEE 754 (including the 1985 version) has
> nothing against rounding attributes (modes) implemented statically.
> And some processors (e.g. ARM FPA, Itanium) implemented static
> rounding attributes before the 2008 version came out.
>
>> In this case, like I mention earlier, I believe "local flag" or
>> "attribute" (which could be implemented as dual op-codes, for
>> example) is best option, i.e., the user must explicitly define the
>> behavior when invoking the function. This way, the user can choose
>>
>> sqrt([-4,-1]) = NaI or sqrt([-4,-1]) = {empty}
>>
>> without needing to remember to check a global status flag after the
>> fact (or without needing to change a global control flag before,
>> either).
>
> That's a possibility, but I'd rather prefer the following one:
>
> sqrt([-4,-1]) = (empty,invalid)
> sqrt([-1,4]) = ([0,2],invalid)
>
> 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, since it requires extra
storage. It also does not provide a mechanism for propagating NaI, like
mentioned above.
Also, it does not generalize to interval functions which may be invalid over
parts of the domain, but then may be valid over other disconnected
intervals. For example, what then is the result of
tan(-100,100) = ?????
As much as c-set reasoning likes to rely on {empty}, it is a convention. In
other mathematical reasoning that does not follow this convention, NaI
really is the true answer sometimes. Efforts to avoid NaI as first-class
citizen I think will narrow the audience and limit the usefulness of 1788.
>
> Also, I said that instead of attaching the "invalid" flag to
> the result, one could have a "status flag" with the meaning of
> IEEE 754-2008. The advantage is that if the program produces
> lots of output, the user does not need to check each result:
> he can simply test the flag.
In my view, checking status flag is the situation to be avoided. If NaI is
returned, user does not need to check the result, since it will propagate
automatically. That is the whole point. NaI is particularly useful in
massively parallel or SIMD environments. Checking flags under these
conditions is error-prone, time consuming.
>
>>>>>> If a counter-example really does exist, the two opcode solution
>>>>>> mentioned above would be better idea, I think.
>>>>>
>>>>> It is not difficult to find counter-examples: the division (e.g.
>>>>> 1/x), tan, arcsin...
>>>>
>>>> If "eps" is smallest machine number, then
>>>>
>>>> 1/([0,3]&[eps,+oo)) = 1/[eps,3] = [1/3,+oo)
>>>
>>> Your reasoning is incorrect. You cannot transform 1/eps into +oo
>>> (this can work with some arithmetics, but not with all of them)!
>>
>> You also cannot transform 1/0 into +oo in all arithmetics, either!
>
> I don't see what you mean: 1/0 is not defined, so is not transformed
> into +oo. The IA implementation must take care of these particular
> inputs.
What I mean is: c-set interpretation (which you advocate as default
behavior), transforms, by implication, 1/0 into +oo:
1/[0,3] = [1/3,1/0] = [1/3,1/0=+oo).
>
>>> Also, 1788 should make the underlying arithmetic transparent. I
>>> mean, the user should not wonder what the smallest machine number
>>> is, for instance.
>>
>> In IEEE 754, user does not need to know what smallest machine number
>> is, but can be guaranteed 1/eps=+oo is always true.
>
> This is not true for all arithmetics, in particular if subnormals
> are not supported.
All 754 formats require subnormals!
Some machines provide a flush-to-normal feature, but the subnormals still
exist in the binary format (they just aren't always produced on output).
>
> Also your expression will no longer be correct if you extend the
> range (because eps depends on the range), and that's really annoying
> and a potential source of bugs.
This is true. It does depend on the range.
>
>>> Yes, you're right for arcsin, but function tan would still be
>>> problematic (and other possible functions not defined in 1788 but
>>> seen as confirming just like what IEEE 754 allows).
>>
>> Tan is only function I can think of that would be likely to need
>> special handling in this case.
>
> You can add gamma functions (that are defined in the C standard,
> and which users may want to be used as conforming functions),
> and probably some special functions that are useful in particular
> applications.