Tim, It appears that atan2_bf() in bigflt.c isn't working correctly. This affects cmplxlog_bf() and thus ComplexPower_bf() in fractalb.c. This can be seen by starting up the manzpower fractal type and then switching to arbitrary precision math using debug=3200. I found this while I was coding the dividebrot5 fractal. In the case of the dividebrot5 fractal, Fractint locks up. With the manzpower fractal, an image is generated, but not the correct one. Jonathan
Jonathan wrote:
It appears that atan2_bf() in bigflt.c isn't working correctly. This affects cmplxlog_bf() and thus ComplexPower_bf() in fractalb.c. This can be seen by starting up the manzpower fractal type and then switching to arbitrary precision math using debug=3200.
Is this executed only in Linux? The corresponding fractint code is in assembler, right? Which version has the bug? Looking at the code, it comes down to a call to unsafe_atan_bf(). We need to make a unit test and find out if the function always fails or just in certain quadrants. Tim
On Sun, 2008-08-03 at 21:34 -0500, Tim Wegner wrote:
It appears that atan2_bf() in bigflt.c isn't working correctly. This affects cmplxlog_bf() and thus ComplexPower_bf() in fractalb.c. This can be seen by starting up the manzpower fractal type and then switching to arbitrary precision math using debug=3200.
Is this executed only in Linux? The corresponding fractint code is in assembler, right? Which version has the bug?
Ugh! With debug=3200 manzpower works fine in Fractint, but not in Xfractint. However, I am coding dividebrot5 in Fractint, so there is a problem with the DOS code. When I hard code some arbitrary numbers in the variables where the atan2_bf() result is stored and comment out the call to atan2_bf(), the dividebrot5 fractal runs. Most of the bigflt code is in C, not assembler. There are only a couple of conversion routines written in assembler. What I am seeing with Xfractint may be due to the 64-bit environment. Don't know about the DOS problem. Jonathan
Tim,
Looking at the code, it comes down to a call to unsafe_atan_bf(). We need to make a unit test and find out if the function always fails or just in certain quadrants.
Definitely a DUH! moment. I needed to call init_big_pi(). There are still some idiosyncrasies to work out. And, the AP math doesn't seem to like the high bailout used by the dividebrot5 fractal type. Haven't had a chance to look at the Xfractint problem. Jonathan
Tim,
And, the AP math doesn't seem to like the high bailout used by the dividebrot5 fractal type.
Fixed this, and the change also fixed the bf version of manzpower in Xfractint. The bailout tests were using a long comparison. Changing the comparison to double fixed things (changed bftoint() to bftofloat()). Currently, the Xfractint float version of dividbrot5 is broken, although the bf math version works. Odd. These changes have been committed to the repository. Working with the bn arbitrary math routines leads me to believe that the problem with the bn version of manzpower is not necessarily a lack of precision as indicated in fractalp.c. I have already found a couple of places where a +shiftfactor should not have been used. Jonathan
Jonathan wrote:
Fixed this, and the change also fixed the bf version of manzpower . > in Xfractint.
That's good news! Do you generally work first with the Linux version? On a totally different topic, how is cedar Rapids recovering? I thought of you a lot during the floods, and made a trip to Wisconsin about that time and saw some evidence of flooding, but nothing like you have experienced. The hurricane was a non-event here in Houston, but I'm sure not for those in Louisiana. Tim
Tim,
Fixed this, and the change also fixed the bf version of manzpower . > in Xfractint.
That's good news! Do you generally work first with the Linux version?
Sometimes, but not this time. I had a good reason to work with the DOS version first when I started, but I can't remember what it was. I think that bftoint() may be broken in Xfractint.
On a totally different topic, how is cedar Rapids recovering? I thought of you a lot during the floods, and made a trip to Wisconsin about that time and saw some evidence of flooding, but nothing like you have experienced.
I rarely go downtown, so I don't have first hand experience with the recovery. The newspaper has articles about businesses that are re-opening, but does not usually talk about the businesses that have failed due to the flood. Obviously, the hardest hit were all the residents that lost their homes. There is talk of buyouts, but I haven't heard a time-line for when that will happen. It's hard to fathom losing everything, and then still having to make mortgage payments while living in a motel or with friends/relatives.
The hurricane was a non-event here in Houston, but I'm sure not for those in Louisiana.
I've managed to be in the remnants of three hurricanes, all a good distance inland. Wouldn't want to every get any closer. Jonathan
Tim,
Currently, the Xfractint float version of dividbrot5 is broken, although the bf math version works. Odd.
Fixed this. Needed to patch FPUcplxlog() in fpu087.c to return (0,0) when the input is (0,0).
Working with the bn arbitrary math routines leads me to believe that the problem with the bn version of manzpower is not necessarily a lack of precision as indicated in fractalp.c. I have already found a couple of places where a +shiftfactor should not have been used.
I have discovered that the call to init_big_pi() gives a segmentation fault when using bn math. Works okay with bf math. Jonathan
participants (2)
-
Jonathan Osuch -
Tim Wegner