Floating Point problem in XFract
By the way, I don't know if anyone else has noticed this before, but in XFractint if you zoom in and zoom in, eventually your (X) resolution drops and drops to 1 (or 0?), so that you just get abunch of horizontal lines. I havn't tracked it down yet, but it happens in Xfract 20.2.x and does *not* happen in Dos fractint 20.2.x. It does seem to correlate with about the time that the dos version switches over to using arbitrary precision. The XFractint version doesn't stop using floating point at the same magnifications. (Like around 10e14 to 10e15) The easiest way to see this bug is, from the first Mandelbrot set, just zoom in on your favorite feature all the way about 11 times, and the (X) resulution should start to drop. (By zoom in all the way, I mean hold <page up> until the zoom box gets as small as it does)
Cute Skunk wrote:
By the way, I don't know if anyone else has noticed this before, > but in XFractint if you zoom in and zoom in, eventually your (X) resolution drops and drops to 1 (or 0?), so that you just get abunch of horizontal lines. I havn't tracked it down yet, but it happens in Xfract 20.2.x and does *not* happen in Dos fractint 20.2.x. It does seem to correlate with about the time that the dos version switches over to using arbitrary precision. The XFractint version doesn't stop using floating point at the same magnifications. (Like around 10e14 to 10e15)
There is some VERY Ad. Hoc. logic for detecting the limits of resolution. Sounds like this is the logic that's not working. The logic is in frasubr.c. Search for variables like ratio_bad. There are some command line variables that let one play with this. Checkout the variable mathtolerance. My suggestion is to add this issue to a todo list for later. It would be a good thing to revevisit after a major rewrite is done. Tim
The easiest way to see this bug is, from the first Mandelbrot set, just zoom in on your favorite feature all the way about 11 times, and the (X) resulution should start to drop. (By zoom in all the way, I mean hold <page up> until the zoom box gets as small as it does)
_______________________________________________ Fractdev mailing list Fractdev@mailman.xmission.com http://mailman.xmission.com/cgi-bin/mailman/listinfo/fractdev
I have tried to reproduce this, but can't. Am using Xfractint 20.02.4, XFree86 4.2.0. My Xfractint window is 640x480. After about 10 max-zoom-ins, I had to increase the max. iterations to 250 just to get some detail. As I'm writing this , I'm working on zoom-in #16. Arbitrary precision is up to 23 decimals, magnification is 2.18356346e+19. I'll save the .par file, in case any one would like to compare the values, but I did start out with the default mandelbrot fractal Scott
Cute Skunk wrote:
By the way, I don't know if anyone else has noticed this before, > but in XFractint if you zoom in and zoom in, eventually your (X) resolution drops and drops to 1 (or 0?), so that you just get abunch of horizontal lines. I havn't tracked it down yet, but it happens in Xfract 20.2.x and does *not* happen in Dos fractint 20.2.x. It does seem to correlate with about the time that the dos version switches over to using arbitrary precision. The XFractint version doesn't stop using floating point at the same magnifications. (Like around 10e14 to 10e15) The easiest way to see this bug is, from the first Mandelbrot set, just zoom in on your favorite feature all the way about 11 times, and the (X) resulution should start to drop. (By zoom in all the way, I mean hold <page up> until the zoom box gets as small as it does)
-- sdboyd56@swbell.net http://sdboyd.dyndns.org
No Microsoft or other proprietary products were used in the creation of this email.
On Mon, 11 Nov 2002, Scott D. Boyd wrote:
I have tried to reproduce this, but can't. Am using Xfractint 20.02.4, XFree86 4.2.0. My Xfractint window is 640x480.
I'm using Xfractint 20.02.3 (from my distro's packager (Slackware)) And 20.02.4 (fo) which I built myself (2.95.3) (libc6 2.2.5) in the default 640x480 window.
After about 10 max-zoom-ins, I had to increase the max. iterations to 250 just to get some detail. As I'm writing this , I'm working on zoom-in #16. Arbitrary precision is up to 23 decimals, magnification is 2.18356346e+19.
I'll save the .par file, in case any one would like to compare the values, but I did start out with the default mandelbrot fractal
Here are some examples (progressive zoom): http://inconnu.isu.edu/~skunky/fract002.gif http://inconnu.isu.edu/~skunky/fract003.gif http://inconnu.isu.edu/~skunky/fract004.gif And speaking of increasing max. iterations... There's another bug on my 20.02.4 (fo) version with get_toggles() or something under that... Here's what I did, pendantically... mkdir clean && cd clean unzip /foo/xfract20.2.04.fo.zip make <start ./xfractint under X11> [default mandelbrot appears] <hit 'x'> [first toggles menu] <change number of iterations to any number (100 for example), 'enter'> [screen redraws as black] <'tab'> [tab says that the iteration count is '2' the lowest possible value] <'tab'> [backout to "Press operation key..."] <'x'> [segmentation fault... 0x080ac1a9 in prompt_valuestring (buf=0xbfffefc8 "0", val=0xbffff1b8) at prompts1.c:715 715 strcpy(buf,val->uval.ch.list[val->uval.ch.val]); I havn't tracked down what it is yet.. it doesn't happen with the 20.02.3 version that came with Slackware.
Cute wrote,
And speaking of increasing max. iterations... There's another bug on my 20.02.4 (fo) version with get_toggles() or something under that...
Perhaps a little history would be in order. The Xfractint float only version was created recently (April) and has not had any use or debugging. There are no versions prior to 20.02.4. After I finish with patch 5, I'll change both my code bases over to the float only source. Jonathan
On Mon, 11 Nov 2002, Jonathan Osuch wrote:
Cute wrote,
And speaking of increasing max. iterations... There's another bug on my 20.02.4 (fo) version with get_toggles() or something under that...
Perhaps a little history would be in order. The Xfractint float only version was created recently (April) and has not had any use or debugging. There are no versions prior to 20.02.4.
After I finish with patch 5, I'll change both my code bases over to the float only source.
Ok... but by the way, here's a fix for that bug... --- orig/prompts2.c 2002-04-21 19:31:41.000000000 -0700 +++ new/prompts2.c 2002-11-14 03:12:23.000000000 -0800 @@ -278,7 +278,9 @@ if (old_usr_stdcalcmode != usr_stdcalcmode) j++; if (old_stoppass != stoppass) j++; +#ifndef XFRACT ++k; /* Floating point line */ +#endif ++k; maxit = uvalues[k].uval.Lval; if (maxit < 0) maxit = old_maxit;
Cute wrote:
Ok... but by the way, here's a fix for that bug...
And, if you were to look at the experimental code (AKA Allegro port) you would notice that fix is already there. We need to decide what the "official" code base is going to be and move my changes and your changes into to it. Jonathan
In article <3DD455D4.7090306@avalon.net>, Jonathan Osuch <osuchj@avalon.net> writes:
We need to decide what the "official" code base is going to be and move my changes and your changes into to it.
I also took about an hour and made a version of your 20.2.03 code with my driver interface and made it compile and link under Win32. I'm using CVS to track my changes to your 20.2.03 zip. -- Ask me about my upcoming book on Direct3D from Addison-Wesley! Direct3D Book <http://www.xmission.com/~legalize/book/> izfree: Open source tools for Windows Installer <http://izfree.sourceforge.net>
Cute wrote:
+#ifndef XFRACT ++k; /* Floating point line */ +#endif
One thing we need to be careful of is that both the Fractint and Xfractint float only versions will have the same problem. Using "#if 0" would be better in this case. Jonathan
On Sun, 10 Nov 2002, Tim Wegner wrote:
The logic is in frasubr.c. Search for variables like ratio_bad.
There are some command line variables that let one play with this. Checkout the variable mathtolerance.
I've been steping through the code a bit... The errors in precision kick in around... Breakpoint 1, ratio_bad (actual=4.842708265645479e-14, desired=4.8405723873656825e-14) at fracsubr.c:777 777 tol = math_tol[1]; ... so I set double math_tol[2]={.05,.0003}; (in cmdfiles.c) and that seems to fix the problem (it switches over to arbitrary precision now just when you can bearly notice the horizontal resolution droping) I'm not sure if this is the best solution or not. A noteworthy side-effect from the earlier bug was that when the screen starts getting blocky, then you can no longer zoom in anymore. Your corners will never change. (And so arbitrary precision will never kick in) (I'm guessing the round-off error is effecting the corners too, or at least the distance between them -- once the corners get rounded off then the ratio will alway be close to 1.0000000.., again arb. prec. will never kick in) (Also towards the higher magnifications (e14..e18) the X and Y deltas seemed to be getting kinda.. out of proportion, like X:Y was over 1:100. But it might be ok, I havn't actually done the math on this yet.) What makes me think that just increasing the tolerance might not be the best solution is that only the testx_try values are becoming inacuarte, the testy_try values are still good for much longer.. for example (testy): Breakpoint 1, ratio_bad (actual=-1.3877787807814599e-17, desired=-1.3877787807814457e-17) at fracsubr.c:777 That's 1.0000000000000102321783533857667315777894704554 When testx's ratio is 1.0020376352163461152038502178961419435419136290
My suggestion is to add this issue to a todo list for later. It would be a good thing to revevisit after a major rewrite is done.
Cute Skunk wrote:
... so I set double math_tol[2]={.05,.0003}; (in cmdfiles.c) and that seems to fix the problem (it switches over to arbitrary precision now just when you can bearly notice the horizontal resolution droping) I'm not sure if this is the best solution or not.
The problem is that Fractint has so many options, not the least are the skewed zoom box options, not to mention different fractal types, that interact with the precision detection. In the end we are probably going to need completely different precision limit detection logic. Maybe even paramters to control it in the fractalspecific structure. Tim
participants (5)
-
Cute Skunk -
Jonathan Osuch -
Rich -
Scott D. Boyd -
Tim Wegner