Re: [PATCH] Fix cexp when both real and imaginary parts of x arenon-finite

["Joseph S. Myers" <joseph at codesourcery dot com>]

On Tue, 31 Jul 2012, Mark H Weaver wrote:

> On 07/31/2012 06:07 PM, Joseph S. Myers wrote:
> > On Tue, 31 Jul 2012, Mark H Weaver wrote:
> > 
> > > The default implementations of cexp, cexpf, and cexpl are broken when
> > > the real part of x is infinite and the imaginary part is non-finite
> > > (infinite or NaN).
> > > 
> > > In these cases, the complex phase of the result is indeterminate, and
> > > thus the only two sensible results are 0.0 + i*0.0 (when the real part
> > > of x is negative infinity) or NaN + i*NaN in all other cases.
> > 
> > I believe the present results are in accordance with what C99 and C11
> > (Annex G) specify  [...]
> 
> The C99 and C11 standards specify behavior that is mathematically incorrect.

I suspect that behavior is linked to the C notion that a complex number 
with at least one part an infinity is a complex infinity, even if the 
other part is a NaN, and trying to define a result that is "a complex 
infinity" in appropriate cases where it can't meaningfully be identified 
as any particular complex infinity.  (If the function were considered as a 
map from a pair of real numbers to a pair of real numbers, then IEEE 
semantics would indeed mean that any NaN in the input would result in a 
NaN output, and infinities would result in NaN outputs where the 
appropriate limit, for each of real and imaginary parts of the result, did 
not exist.)

> Apparently too few people involved in C standardization understand complex
> exponentials.  What a damn shame.  I will have to avoid using cexp in Guile.

If the semantics required for Guile differ from the C semantics for 
infinite arguments, that doesn't stop you using cexp for finite arguments.  
There have been various fixes to cexp and other complex functions in 2.16 
to avoid internal overflows and underflows where the final results don't 
have such overflows and underflows, and to improve accuracy in various 
cases (where previously the functions generally used naive algorithms that 
would be mathematically correct if all the values were exact, but have 
problems in practice with floating-point numbers), and more such fixes 
since 2.16.

-- 
Joseph S. Myers
joseph@codesourcery.com