Complex arg-trig functions

[Bruce Evans]

I will be away for a couple of weeks.  Hope nothing happens :-).

On Wed, 15 Aug 2012, Stephen Montgomery-Smith wrote:

> On 08/15/2012 04:49 PM, Stephen Montgomery-Smith wrote:
>> On 08/15/2012 03:42 PM, Stephen Montgomery-Smith wrote:
>>> 
>>> All your solutions depend upon using (1-tiny) with the result being
>>> used.  But what if FE_DOWNWARD is set?  Then 1-tiny becomes
>>> 1-DBL_EPSILON.  And then if the result is used, everything is off by 1
>>> ulp.

Yes, this is another example that msun depends a lot on the default
rounding mode.

>>> And
>>> if ((int)(1 - tiny) == 1)
>>> will fail.

But this can be fixed to ((int)(1 + tiny) == 0).  I was originally going
to use addition, but then grep showed fdlibm mostly using subtraction.
At least some uses of (one - tiny) seem to be intentional.  E.g.,
s_tanh.c returns +-(one - tiny) for the asymptotes to value +-1.
Although 1 would be more accurate, if the rounding mode is unusual
then the caller must actually want the less accurate value that results
from not rounding to nearest.  (one - tiny) is always <= 1.  This is
consistent with the asymptote always being < 1.

>> How about replacing
>> 
>>      if (huge+ax>one && huge+bx>one) ....
>> 
>> with
>> 
>>      if ((int)(1/ax)==0 || (int)(1/bx)==0) ....
>> 
>> (We know that one of ax or bx is larger than 1.)
>
> if ((int)(1/(2+ax))==0) ....
>
> (because one of ax or bx might be 0).

Now it is getting too heavyweight.  Although this is not a fast path,
a division in it makes it really slow.

Bruce