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).

Thanks,

Luc J. Bourhis

I typed without thinking: it’s (rho*cos(theta + pi), rho*sin(theta + pi)) of course

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