FOTD 12-08-07 renders wrong in xfractint
Here's another one that looks like a difference between C parser and asm parser. Compare: <http://www.nahee.com/FOTD/FotD_07-08-12.html> <http://www.xmission.com/~legalize/fractals/fotd/2007/08/2007.08.12-Straight_Forward.jpg> ; Date: Sat, 11 Aug 2007 22:43:46 -0400 ; ; To: fractint@mailman.xmission.com ; cc: philofractal@lists.fractalus.com ; ; From: Jim Muth <jamth@mindspring.com> ; Reply-To: Fractint and General Fractals Discussion ; <fractint@mailman.xmission.com> ; ; Subject: [Fractint] FOTD 12-08-07 (Straight Forward [9]) ; ; Id: <1.5.4.16.20070811224929.2a5fb0f2@pop.mindspring.com> ; --------- ; ; FOTD -- August 12, 2007 (Rating 9) ; ; Fractal visionaries and enthusiasts: ; ; It's nice to escape the endless spirals that fill so many ; fractals. In today's image we escape them with a vengeance. ; There are no spirals in today's image. In fact there are no ; curved elements at all. Some of the elements do have jagged ; edges, but the overall shapes radiate from the central midget ; straight as an arrow. In recognition of all this straightness, ; I named today's image "Straight Forward". ; ; While I was coloring the image, I had an attack of serendipity. ; The colors flashed onto the screen ready-to-go, complete with ; the bright white band. I needed to tweak only about 10 color ; registers to create today's outstandingly moody color palette. ; ; The colors are what raises the rating to a superior 9. And it ; is an honest 9, not a typing error like the 9 I typed by mistake ; three days ago, when the image actually rated only a 6. ; ; In today's formula I subtracted 20 parts of Z^(1.01) from 20 ; parts of Z^(0.99) and added C. The 20 parts are necessary ; because the actual difference between the two exponents is so ; small that nothing but a blank screen is produced unless the ; difference is magnified. And even with the difference magnified ; 20 times, the parent fractal is grossly oversized, making the ; excessive escape radius of 1000 still necessary. ; ; The parent fractal is another Mandeloid rotated 180 degrees, ; similar to the parent fractals of the past several fractal ; images. Today's scene is located at the extreme western edge of ; the chaos, very close to the X-axis. The mathtolerance entry is ; necessary to assure that the image generates from the parameter ; file at the correct magnitude. ; ; I was sorely tempted to position the midget away from the center ; of the frame, somewhere near one of the upper 1/3-1/3 points, ; which would have added additional tension to the scene. If the ; purpose of the image were artistic, I would have done so, but ; the FOTD images are for mathematical interest rather than an ex- ; hibition of art, so I kept the midget centered and in the normal ; orientation. There is no rule stating that midgets must always ; be centered however. I might start adding tension to future ; images by eliminating the all-too-common symmetry around the ; center of the frame. ; ; At just over 1 minute, the calculation time of today's image is ; quite short. And considering the rating of a 9, it is quite a ; bargain. It's also a bargain to see the image already rendered ; on the FOTD web site at: ; ; <http://home.att.net/~Paul.N.Lee/FotD/FotD.html> ; ; The weather was perfect here at Fractal Central on Saturday, ; a day that would make any outdoor activity a pleasure. The ; fractal cats' day was near perfect; the FOTD fractal is near ; perfect, and the commercial work is totally under control. I ; don't want to tempt fate by saying that everything was totally ; perfect all day, but it came close. ; ; The next FOTD will appear on schedule in 24 hours. Until then, ; take care, and keep alert. ; ; ; Jim Muth ; jamth@mindspring.com ; jimmuth@aol.com ; ; ; START PARAMETER FILE======================================= Straight_Forward { ; time=0:01:15.55-SF5 on P4-2000 reset=2004 type=formula formulafile=allinone.frm formulaname=MandAutoCritInZ function=ident passes=1 center-mag=-10.61536422079259/+0.00000051589073515\ /6.265924e+011/1/-45.877/-0.0058784538 params=20/\ 0.99/-20/1.01/0/1000/0/0 float=y maxiter=15000 inside=0 periodicity=10 mathtolerance=0.05/1 colors=000zsCvqFrpIooLknOhmRdlUajXYi_VhbRgeOfhKekH\ dnTwrWvqYup_uoatndsmfslhrkjrjilhhffgadfWbeR`dLZcGX\ bAVb5TLPR9uEDsGGqHJoJMmKQkMTiNWgPZeQbcSeaTh_VkZWm`\ Ynb_odapecqgerigtjiulkvnmwooxqqysszttruujuucvvWvvP\ wwHwwAwwCouEhtFasHUrJNqKGpJEqHDrGCscMmzVgsRb201mOZ\ gLU`IQVFMPCHI9DC68634HaNG_LFYKEWJDVIDTHCRGBPFAOEAM\ D9KC8JB7HA6F96D85C74A6385364253132011N7bL6_K6YJ5WI\ 5UG5SF4QE4OD4MC3KA3I92G82E72C61A4183162041029Gb8F`\ 8EZ7DX7CV6CT6BR5AP59N48L48J47H36F35D24B24913712501\ 3001RMgLHZGDQA8H548WZqPSfJLWCEL67AswzLPjMNiNLhOJgP\ HfQFeQDdNEbKEaHE_EEZBFX8FW5FU3FT7IVALXEOYHR_KUaOXb\ R_dUbfYeg`hicjj`ggYddWbaT_ZQXWOVTLSQIPNGNKDKHAHE8F\ B5C82950734D58J6BP7FV9I_AMeBPkDTqEWvFzw0zw0zw0zw0z\ w0zx0zx0VxcVxcVxcVxcVycVydVyfVyzVyzVzzVzzVzzVzzVzz\ VzzUzzUzzUzzUzzUmkTkiTigTfdTdbTa`T_ZSYXSVVSTTSQQSO\ ORMMRJKRHIREGRCERACPBEOCF } frm:MandAutoCritInZ {; Jim Muth a=real(p1), b=imag(p1), d=real(p2), f=imag(p2), g=1/f, h=1/d, j=1/(f-b), z=(((-a*b*g*h)^j)+(p4)), k=real(p3)+1, l=imag(p3)+100, c=fn1(pixel): z=k*((a*(z^b))+(d*(z^f)))+c, |z| < l } ; END PARAMETER FILE========================================= ; ; ; _______________________________________________ ; Fractint mailing list ; Fractint@mailman.xmission.com ; http://mailman.xmission.com/cgi-bin/mailman/listinfo/fractint -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download <http://legalizeadulthood.wordpress.com/the-direct3d-graphics-pipeline/> Legalize Adulthood! <http://legalizeadulthood.wordpress.com>
In article <E1OW2S2-0004zz-M0@shell.xmission.com>, Richard <legalize@xmission.com> writes:
Here's another one that looks like a difference between C parser and asm parser.
I guess technically, we shouldn't blame the C code. Perhaps its the asm code that's wrong. -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download <http://legalizeadulthood.wordpress.com/the-direct3d-graphics-pipeline/> Legalize Adulthood! <http://legalizeadulthood.wordpress.com>
In article <E1OW2XC-0006yZ-MN@shell.xmission.com>, Richard <legalize@xmission.com> writes:
In article <E1OW2S2-0004zz-M0@shell.xmission.com>, Richard <legalize@xmission.com> writes:
Here's another one that looks like a difference between C parser and asm parser.
I guess technically, we shouldn't blame the C code. Perhaps its the asm code that's wrong.
Digging a little deeper: MandAutoCritInZ is used all over Jim's FOTDs, but only a couple of them render differently. -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download <http://legalizeadulthood.wordpress.com/the-direct3d-graphics-pipeline/> Legalize Adulthood! <http://legalizeadulthood.wordpress.com>
Rich, Yes, the problem here is the difference between using 80-bit reals and 64-bit reals. Jonathan
Here's another one that looks like a difference between C parser and asm parser.
Compare: <http://www.nahee.com/FOTD/FotD_07-08-12.html> <http://www.xmission.com/~legalize/fractals/fotd/2007/08/2007.08.12-Straight_Forward.jpg>
; FOTD -- August 12, 2007 (Rating 9) ; ; START PARAMETER FILE=======================================
Straight_Forward { ; time=0:01:15.55-SF5 on P4-2000 reset=2004 type=formula formulafile=allinone.frm formulaname=MandAutoCritInZ function=ident passes=1 center-mag=-10.61536422079259/+0.00000051589073515\ /6.265924e+011/1/-45.877/-0.0058784538 params=20/\ 0.99/-20/1.01/0/1000/0/0 float=y maxiter=15000 inside=0 periodicity=10 mathtolerance=0.05/1 colors=000zsCvqFrpIooLknOhmRdlUajXYi_VhbRgeOfhKekH\ dnTwrWvqYup_uoatndsmfslhrkjrjilhhffgadfWbeR`dLZcGX\ bAVb5TLPR9uEDsGGqHJoJMmKQkMTiNWgPZeQbcSeaTh_VkZWm`\ Ynb_odapecqgerigtjiulkvnmwooxqqysszttruujuucvvWvvP\ wwHwwAwwCouEhtFasHUrJNqKGpJEqHDrGCscMmzVgsRb201mOZ\ gLU`IQVFMPCHI9DC68634HaNG_LFYKEWJDVIDTHCRGBPFAOEAM\ D9KC8JB7HA6F96D85C74A6385364253132011N7bL6_K6YJ5WI\ 5UG5SF4QE4OD4MC3KA3I92G82E72C61A4183162041029Gb8F`\ 8EZ7DX7CV6CT6BR5AP59N48L48J47H36F35D24B24913712501\ 3001RMgLHZGDQA8H548WZqPSfJLWCEL67AswzLPjMNiNLhOJgP\ HfQFeQDdNEbKEaHE_EEZBFX8FW5FU3FT7IVALXEOYHR_KUaOXb\ R_dUbfYeg`hicjj`ggYddWbaT_ZQXWOVTLSQIPNGNKDKHAHE8F\ B5C82950734D58J6BP7FV9I_AMeBPkDTqEWvFzw0zw0zw0zw0z\ w0zx0zx0VxcVxcVxcVxcVycVydVyfVyzVyzVzzVzzVzzVzzVzz\ VzzUzzUzzUzzUzzUmkTkiTigTfdTdbTa`T_ZSYXSVVSTTSQQSO\ ORMMRJKRHIREGRCERACPBEOCF }
frm:MandAutoCritInZ {; Jim Muth a=real(p1), b=imag(p1), d=real(p2), f=imag(p2), g=1/f, h=1/d, j=1/(f-b), z=(((-a*b*g*h)^j)+(p4)), k=real(p3)+1, l=imag(p3)+100, c=fn1(pixel): z=k*((a*(z^b))+(d*(z^f)))+c, |z| < l }
; END PARAMETER FILE=========================================
In article <1278552249.1945.3.camel@jonathan-desktop>, Jonathan Osuch <osuchj@avalon.net> writes:
Yes, the problem here is the difference between using 80-bit reals and 64-bit reals.
Do we know *exactly* why this is the case for this particular parset? By that, I mean do we know which line of code produces different results? -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download <http://legalizeadulthood.wordpress.com/the-direct3d-graphics-pipeline/> Legalize Adulthood! <http://legalizeadulthood.wordpress.com>
Rich, Do you mean which line in the MandAutoCritInZ formula, or do you mean which line in the parsers? The parsers inherently operate at different precisions and when the level of zoom is high enough or the complexity of the calculations is high, there are going to be differences in the images generated. As for the formula, there are a ton of calculations going on. I might get rid of the g and h variables and just do one divide in the initial calculation of z, but I doubt it would make much difference. Jonathan
Yes, the problem here is the difference between using 80-bit reals and 64-bit reals.
Do we know *exactly* why this is the case for this particular parset?
By that, I mean do we know which line of code produces different results?
In article <1278637131.1858.14.camel@jonathan-desktop>, Jonathan Osuch <osuchj@avalon.net> writes:
Do you mean which line in the MandAutoCritInZ formula, or do you mean which line in the parsers?
It could be either way; either we find the offending bit in the formula or in the code. The formula isn't universally offending, because depending on parameter values it usually renders the same on both. Are we just saying "its a precision issue" and throwing up our hands, or are we trying to achieve parity? If the former, then I guess there's no reason to continue the conversation; if the latter, then we should try to find out where/when we need more precision in the "C" code and go to bignums.
The parsers inherently operate at different precisions and when the level of zoom is high enough or the complexity of the calculations is high, there are going to be differences in the images generated.
I would have thought that bignums would kick in if it was a zoom issue. -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download <http://legalizeadulthood.wordpress.com/the-direct3d-graphics-pipeline/> Legalize Adulthood! <http://legalizeadulthood.wordpress.com>
Rich, The formula parser doesn't support bignums. If it did, that would be an ideal solution. I do have some parser assembly code that I converted to nasm and linked to Xfractint. It runs, but produces a blank screen. For various reasons, I've been unable to get back to working on it. My current plans are to get my SDL port working a little better and then either linking this parser code or rewriting it using inline assembly in C. Jonathan
Are we just saying "its a precision issue" and throwing up our hands, or are we trying to achieve parity? If the former, then I guess there's no reason to continue the conversation; if the latter, then we should try to find out where/when we need more precision in the "C" code and go to bignums.
The parsers inherently operate at different precisions and when the level of zoom is high enough or the complexity of the calculations is high, there are going to be differences in the images generated.
I would have thought that bignums would kick in if it was a zoom issue.
In article <1278715622.1718.9.camel@jonathan-desktop>, Jonathan Osuch <osuchj@avalon.net> writes:
The formula parser doesn't support bignums. If it did, that would be an ideal solution.
Ahhhhhhh. That explains it, then. I forgot bignums were just for a few fractal types (M and J set?). -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download <http://legalizeadulthood.wordpress.com/the-direct3d-graphics-pipeline/> Legalize Adulthood! <http://legalizeadulthood.wordpress.com>
participants (2)
-
Jonathan Osuch -
Richard