Re: libstdc++/10689: pow(std::complex(0),1/3) returns (nan, nan) instead of 0.

Re: libstdc++/10689: pow(std::complex(0),1/3) returns (nan, nan) instead of 0.

[Dara Hazeghi]

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;
 }
 

Re: libstdc++/10689: pow(std::complex(0),1/3) returns (nan, nan) instead of 0.

[gdr]

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

Re: libstdc++/10689: pow(std::complex(0),1/3) returns (nan, nan) instead of 0.

[Gabriel Dos Reis]

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

Re: libstdc++/10689: pow(std::complex(0),1/3) returns (nan, nan) instead of 0.

[bkoz]

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

libstdc++/10689: pow(std::complex(0),1/3) returns (nan, nan) instead of 0.

[Daniel.Levine]

>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: