Re: A proposal for the next motion
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.
>>>
>>> Flags are part of the IEEE 754 standard. That's why I mentioned
>>> them. And there are no problems with multi-core, multi-threaded
>>> environments. This is just a matter of implementation, which can be
>>> efficient or not.
>>
>> I don't agree. Flags can be problematic and source of performance
>> loss in massively parallel applications. The problem is exacerbated
>> in SIMD processing environments. A propagating NaI is more efficient
>> in these scenarios.
>>
>> IEEE 754-2008 re-words parts of the standard to get away from the
>> global flags concept.
>
> 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.
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.
>>>>> This is not acceptable. In particular, what would you do if the
>>>>> natural domain of the function is not an interval or is an
>>>>> interval having an endpoint that is not an exactly representable
>>>>> number?
>>>>
>>>> For the mathematical functions likely to be included in a 1788
>>>> standard, the natural domain can be represented by machine numbers.
>>>
>>> The behavior should be general enough to be extended to common
>>> functions that would not necessarily be in the 1788 standard.
>>
>> I don't see why.
>
> Because the user may need other functions. For instance, the C
> language defines more functions than IEEE 754. So does LIA. But such
> functions
> can be seen as conforming to IEEE 754; see 9.1:
>
> For one or more formats, language standards and implementations
> might define one or more floating-point functions, not otherwise
> defined in this document, that conform to this standard by meeting
> all the requirements of this subclause.
>
> 1788 should have a clause like that too.
Ok. I accept it is a good point.
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).
It is a solution I believe should be acceptable to both c-set and modal
interval users.
However, notice in this case there is no "default" behavior, since strictly
speaking the "local flag" or "attribute" is explicitly specified at the time
the function is invoked.
>>>> 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!
This is why there must be a mechanism for user to choose
1/[0,3]=NaI or 1/[0,3]=[1/3,+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.
>
> And the user should not have to reimplement interval arithmetic or
> parts of it (like determining special points in an interval, such
> as points on which the function is not defined -- that may be quite
> difficult, e.g. for tan).
I agree for tan a special provision would need to be made.
Otherwise, I believe the "local flag" or "attribute" idea is best option.
>
>> produces correct result in floating-point. I don't know if trig
>> functions will be included in 1788 or not, but the natural domain of
>> all inverse trig functions (even the inverse hyperbolic functions)
>> are easily represented exactly in floating-point, e.g, the natural
>> domain of arcsin is [-1,1].
>
> 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.
But I would be happy with the "local flag" or "attribute" idea mentioned
earlier. That is a good general-purpose solution that meets requirements of
both c-set and modal intervals while not favoring or compromising one for
the other.
Nate