[cfe-dev] [libc++] std::polar(rho, theta) bogus for theta < 0?

[Howard Hinnant]

On Nov 14, 2013, at 1:40 PM, Luc Bourhis <luc_j_bourhis at mac.com> wrote:

> Hi,
> 
> polar(rho, theta) returns (NaN, NaN) if rho < 0. The code responsible for that behaviour is in the first two lines of the body of polar:
> 
>    if (isnan(__rho) || signbit(__rho))
>        return complex<_Tp>(_Tp(NAN), _Tp(NAN));
> 
> libstdc++, on the contrary, returns (rho*cos(theta), rho*sin(theta)) in this case.
> 
> The standard says "Returns: the complex value corresponding to a complex number whose magnitude is rho and whose phase angle is theta."
> It seems to favour libc++ choice over libstdc++ one but it is a real pain when the two major standard libraries on current platforms disagree in such a manner.
> We have hit that bug hard in the Computational Crystallography Toolbox, which has to run on MacOS, Linuxes (and Windows but that's another story).


I've read this over several times.  I've consulted C++11, C11, and IEC 10967-3.  I can find nothing to support the libstdc++ implementation.

I'm finding:

1.  The magnitude of a complex number == abs(c) == hypot(c.real(), c.imag()) and is always non-negative (by all three of the above standards).

2.  Therefore no complex number exists for which abs(c) < 0.

3.  Therefore when the first argument to std::polar (which is called rho) is negative, no complex number can be formed which meets the post-conidtion that abs(c) == rho.  Returning a complex NAN is consistent with all of the other complex operations in the libc++ <complex> which follows the guidelines set up in Annex G of C99/C11.

Sorry about the pain of your porting.  Is not a bug report against libstdc++ in order?

Howard