Re: A proposal for the next motion
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.
>>> 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.
>> 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)
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].
Nate