The function ComplexPower() in mpmath_c.c apparently has a bug. The bug appears to be in the Linux also - I tried runninmg it, but haven't checked the code. If so, someone did an incredible job of translating the assembler! I instrumented StkPwr in parser.c to print out the arguments and the result. I found this wehnen running Jim White's example: Arg1: 0.166666666666667 0.000000000000000 Arg2: -5.000000000000000 0.000000000000000 Result: 1.132467200411351 -0.653830243005915 Arg1: 0.166666666666667 0.000000000000000 Arg2: -5.000000000000000 0.000000000000000 Result: 1.132467200411351 0.653830243005915 In two subsequent calls, the sign of the imaginary part changed despite the arguments being the same!! The problem is in ComplexPower() in mpmath_c.c. I was able to make the symtoms go away by replacing the FPUcplxlog function with C: /* FPUcplxlog(&xx, &cLog); */ cLog.x = .5*log(xx.x*xx.x + xx.y*xx.y); cLog.y = atan2(xx.y,xx.x); That's as far as I got. WIll take this up again soon. Tim
On Thursday 29 May 2003 12:40 am, Tim Wegner wrote:
I found this when running Jim White's example:
Arg1: 0.166666666666667 0.000000000000000 Arg2: -5.000000000000000 0.000000000000000 Result: 1.132467200411351 -0.653830243005915 Arg1: 0.166666666666667 0.000000000000000 Arg2: -5.000000000000000 0.000000000000000 Result: 1.132467200411351 0.653830243005915
The problem could be the 0.166666666666667, and not the -5.0, since it does not have an exact representation in binary. Jonathan
Responding to a message from Jonathan that got caught in the Yahoo SPAM filter :-) :
I found this when running Jim White's example:
Arg1: 0.166666666666667 0.000000000000000 Arg2: -5.000000000000000 0.000000000000000 Result: 1.132467200411351 -0.653830243005915 Arg1: 0.166666666666667 0.000000000000000 Arg2: -5.000000000000000 0.000000000000000 Result: 1.132467200411351 0.653830243005915
The problem could be the 0.166666666666667, and not the -5.0, since it does not have an exact representation in binary.
I wrote the entire 64 bit address space out in hexidecimal for both real and imaginary parts of the argument, and they were the same, though the Log function returned different results. I guess we are looking in the wrong place. We should look in the parser code that multiplies numbers. Something about the series of multiples leaves something different that causes the subsequent log() function to return a different value. Tim
On Monday 02 June 2003 11:58 pm, Tim Wegner wrote:
I guess we are looking in the wrong place. We should look in the parser code that multiplies numbers. Something about the series of multiples leaves something different that causes the subsequent log() function to return a different value.
The FPUcplxmul code in FPU087.asm looks okay to me. Although, the problem could be that the multiplies by zero return a -zero. However, the Xfractint version of FPUcplxdiv in FPU087.c does not handle the case of a zero mod correctly (or at all, basically). Jonathan
On Tuesday 03 June 2003 09:45 pm, Tim Wegner wrote:
The FPUcplxmul code in FPU087.asm looks okay to me. Although, the problem could be that the multiplies by zero return a -zero.
The exact multiplies prior to the are:
(-1)*(-5)(1)(-1) = -5
vs just plain -5.
And does using: (-1,0)*(-5,0)*(1,0)*(-1,0) make any difference? Is it a problem with taking the real numbers and turning them into complex pairs? Jonathan
And does using:
(-1,0)*(-5,0)*(1,0)*(-1,0)
make any difference? Is it a problem with taking the real numbers and turning them into complex pairs?
Sorry, I wasn't writing exactly. The actual code is: a = 1, b = -5, g = 1, h = -1, j = 1/6 z = (-a*b*g*h)^j ; the expression in question ; -a*g*h = 1, so z =b^j [i.e. -5 ^(1/6)] z2 = b^j ; correct answer The calculation of z gives a different result than the calculation of z2. I instrumented the dStkPwr function in parser.c, and ran fractint with debug=90. I verified that the argment (-5,0) is the same when the StkPwr function is called in both cases. I don't mean to re-open this discussion (but I guess I have :-) because I have figured out almost everything about this problem. If you trace further down stream, the (-5,0) argument gets into ComplexPower() in mpmath_c.c, and then FPUcplxlog(&xx, &cLog); This is the function that returns different results. The (-5,0) argument lies on a discontinuity of the Log function which explains most of the mysterious behavior. The only thing I can't explain is why FPUcplxlog() returns different values with the identical argument (both results are "correct" mathematically). I am not suggesting this is worth a further look by you. But if it interests you enough to look further, go ahead. If you want the complete example, let me know. I have seen similar behavior with and without debug=90 and with Xfractint. However, if I replace the FPUcplxlog call in ComplexPower with a hand-coded Log (same code as in Xfractint) the symptoms go away. The two values returned by Log are both correct (or very very nearly so) - the mystery is only what is causing different answers. Tim
participants (2)
-
Jonathan Osuch -
Tim Wegner