This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug math/14473] Inaccurate CPOW* function on all machines.
- From: "mwelinder at gmail dot com" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Fri, 06 Dec 2013 14:07:38 +0000
- Subject: [Bug math/14473] Inaccurate CPOW* function on all machines.
- Auto-submitted: auto-generated
- References: <bug-14473-131 at http dot sourceware dot org/bugzilla/>
https://sourceware.org/bugzilla/show_bug.cgi?id=14473
M Welinder <mwelinder at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |mwelinder at gmail dot com
--- Comment #5 from M Welinder <mwelinder at gmail dot com> ---
There are at least two classes of accuracy issues with cpow(z,z2):
(1) Insufficient precision in intermediate results, affecting primarily "large"
arguments
(2) Bad handling of |z1| == 1. Sample program below. This is actually
easy to solve: use atan2pi, sinpi, and cospi instead of atan2, sin, and
cos.
#include <complex.h>
#include <stdio.h>
#include <math.h>
int dont_optimize = 0;
int
main (int argc, char **argv)
{
double complex z1, z2, z;
/*
* z here should be real. I see an imaginary part of
* 2.54571e-17, except when gcc is allowed to optimize
* the whole thing at compile time. Exact result should
* be -exp(-pi/2) =~ -0.20788
*
* Surprise: Mathematica gets it wrong too. I see the
* same value as gcc for N[I^(I+2)].
*/
z1 = dont_optimize + I;
z2 = 2 + I;
z = cpow (z1, z2);
printf ("%g + %g i\n", creal (z), cimag (z));
/*
* Really scary version. Exact result is exp(-pi/2)
* =~ 0.20788. I see "0.177058 + -0.108924 i".
*/
z2 = ldexp (1,53) + I;
z = cpow (z1, z2);
printf ("%g + %g i\n", creal (z), cimag (z));
return 0;
}
--
You are receiving this mail because:
You are on the CC list for the bug.