>Number: 10689 >Category: libstdc++ >Synopsis: pow(std::complex(0),1/3) returns (nan, nan) instead of 0. >Confidential: no >Severity: non-critical >Priority: medium >Responsible: unassigned >State: open >Class: wrong-code >Submitter-Id: net >Arrival-Date: Thu May 08 18:16:00 UTC 2003 >Closed-Date: >Last-Modified: >Originator: Daniel Levine >Release: gcc 3.2-7 >Organization: >Environment: Any. >Description: Executing the pow(0,y) function call for doubles correctly produces return values of 0 as long as y != 0. Doing the same with the pow(std::complex<double>(0),y) will return (nan, nan). This appears to be caused by the log(x) when x is 0 returning nan as it should. Further exp() will never return 0 so some check needs to be implemented so pow(std::complex<double>(0),y) can return 0 when y != 0. This problem is not specific to complex<double>. Other complex floating point types would suffer from the same problem. One final note, pow(std::complex<double>(0), 1) works because it triggers other code while pow(std::complex<double>(0), 1.0) fails. >How-To-Repeat: #include <iostream> using namespace std; complex<double> complexZero; complex<double> cubeRootOf0 = pow(complexZero, 1.0/3.0); cerr << cubeRootof0 << endl; // Should be 0.0; complex<double> zeroToThe1.0 = pow(complexZero, 1.0); cerr << zeroToThe1.0 << endl; // Should be 0.0; complex<double> zeroToThe1 = pow(complexZero, 1); cerr << zeroToThe1 << endl; // Is 0.0; >Fix: >Release-Note: >Audit-Trail: >Unformatted:
The following reply was made to PR libstdc++/10689; it has been noted by GNATS. From: Dara Hazeghi <dhazeghi@yahoo.com> To: gcc-gnats@gcc.gnu.org, Daniel.Levine@jhuapl.edu Cc: Subject: Re: libstdc++/10689: pow(std::complex(0),1/3) returns (nan, nan) instead of 0. Date: Sat, 10 May 2003 12:26:42 -0700 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit- trail&database=gcc&pr=10689 Hello, I can confirm this problem with 3.3 branch and mainline (20030508). However, next time you send in a testcase, make sure it compilers first. Dara #include <iostream> #include <complex> using namespace std; int main() { complex<double> complexZero; complex<double> cubeRootof0; complex<double> zeroToThe1; cubeRootof0 = pow(complexZero, 1.0/3.0); cerr << cubeRootof0 << endl; // Should be 0.0; zeroToThe1 = pow(complexZero, 1.0); cerr << zeroToThe1 << endl; // Should be 0.0; zeroToThe1 = pow(complexZero, 1); cerr << zeroToThe1 << endl; // Is 0.0; }
Synopsis: pow(std::complex(0),1/3) returns (nan, nan) instead of 0. Responsible-Changed-From-To: unassigned->gdr Responsible-Changed-By: bkoz Responsible-Changed-When: Fri May 16 20:04:27 2003 Responsible-Changed-Why: Maybe you could triage this? It's either runtime or __builtin I think. best, benjamin http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=10689
The following reply was made to PR libstdc++/10689; it has been noted by GNATS. From: Gabriel Dos Reis <gdr@integrable-solutions.net> To: bkoz@gcc.gnu.org Cc: Daniel.Levine@jhuapl.edu, gcc-bugs@gcc.gnu.org, gcc-gnats@gcc.gnu.org Subject: Re: libstdc++/10689: pow(std::complex(0),1/3) returns (nan, nan) instead of 0. Date: 18 May 2003 14:57:42 +0200 bkoz@gcc.gnu.org writes: | Synopsis: pow(std::complex(0),1/3) returns (nan, nan) instead of 0. | | Responsible-Changed-From-To: unassigned->gdr | Responsible-Changed-By: bkoz | Responsible-Changed-When: Fri May 16 20:04:27 2003 | Responsible-Changed-Why: | Maybe you could triage this? It's either runtime or __builtin I think. It is not __builtin. It is runtime. A proper way to fix this is to to use __builtin where appropriate and runtime where not. The traditional approach is through traits. Will handle that, after I applied the name lookup patch. This week is too heavy... -- Gaby
Synopsis: pow(std::complex(0),1/3) returns (nan, nan) instead of 0. State-Changed-From-To: open->closed State-Changed-By: gdr State-Changed-When: Tue May 20 06:53:13 2003 State-Changed-Why: Fixed. http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=10689