Today's fractal is an illustration from "Max Iter's Field Guide to Imitation Minibrots". Like yesterday's fractal this is a minibrot wannabee. Unlike yesterday's fractal it is politely symmetrical not unnervingly twisted. However even the most cursory examination of the nose and side buds show it to be not a true minibrot. As the French say C'est le vino, or something like that. Ready made at http://maxitersfractalfollies.blogspot.com fract437.gif { ; almost a minibrot ; blank ; calctime 0:03:58.87 ; created Sep 25, 2010 ; Fractint Version 2004 Patchlevel 9 reset=2004 type=formula formulafile=_s.frm formulaname=SuperNuker function=sin/sqr center-mag=-0.65381727158948720/-0.00050083472454090/127.6748/1/90/-1.23\ 373533611470521e-014 float=y maxiter=1500 inside=0 colors=00000000200400600800A00C00E00G00I00K00M00O00Q00S00U00W00Y00_00a00\ c00e00g00i00k00m00o00q00s00u00w00z01z03z05z07z09z0Bz0Dz0Fz0Hz0Jz0Lz0Nz0P\ z0Rz0Tz0Vz0Xz0Zz0`z0bz0dz0fz0hz0jz0lz0nz0pz0rz0tz0vz0xz0zz0zz0yz0xz0wz0v\ z0uz0tz0sz0rz0qz0pz0oz0nz0mz0lz0kz0jz0iz0hz0gz0fz0ez0dz0cz0bz0az0`z0_z0Z\ z0Yz0Xz0Wz0Vz0Uz0Tz0Sz0Rz0Qz0Pz0Oz0Nz0Mz0Lz0Kz0Jz0Iz0Hz0Gz0Fz0Ez0Dz0Cz0B\ z0Az09z08z07z06z05z04z03z02z01z00z00z03z07z0Bz0Fz0Jz0Nz0Rz0Vz0Zz0bz0fz0j\ z0nz0rz0vz0uz1tz1sz2rz3pz3oz4nz5mz5kz6jz7iz7hz8gz9ez9dzAczBbzB`zC_zDZzDY\ zEWzFVzFUzGTzHSzHQzIPzJOzJNzKLzLKzLJzMIzNGzNFzOEzPDzPCzQAzR9zR8zS7zT5zT4\ zU3zV2zW0zW0zV0yV0xU0wU0vT0uT0tS0sS0rR0qR0pQ0oQ0nP0mP0lO0kO0jN0iN0hM0gM0\ fL0eL0dK0cK0bJ0aJ0`I0_I0ZH0YH0XG0WG0VF0UF0TE0SE0RD0QD0PC0OC0NB0MB0LA0KA0\ J90I90H80G80F70E70D60C60B50A509408407306305204203102101 } frm:SuperNuker {; Justin Kolodziej ; mod. of Mr. Newstead's Nuke1 z = 0 c = pixel d = fn2(pixel): z = (fn1(z)+c)/d } Roger Alexander
In article <BAY156-w9069C2613C125B1183721DE640@phx.gbl>, Roger Alexander <maxiterfractal@hotmail.com> writes:
fract437.gif { ; almost a minibrot ; blank ; calctime 0:03:58.87 ; created Sep 25, 2010 ; Fractint Version 2004 Patchlevel 9 reset=2004 type=formula formulafile=_s.frm formulaname=SuperNuker function=sin/sqr center-mag=-0.65381727158948720/-0.00050083472454090/127.6748/1/90/-1.23\ 373533611470521e-014 float=y maxiter=1500 inside=0 colors=00000000200400600800A00C00E00G00I00K00M00O00Q00S00U00W00Y00_00a00\ c00e00g00i00k00m00o00q00s00u00w00z01z03z05z07z09z0Bz0Dz0Fz0Hz0Jz0Lz0Nz0P\ z0Rz0Tz0Vz0Xz0Zz0`z0bz0dz0fz0hz0jz0lz0nz0pz0rz0tz0vz0xz0zz0zz0yz0xz0wz0v\ z0uz0tz0sz0rz0qz0pz0oz0nz0mz0lz0kz0jz0iz0hz0gz0fz0ez0dz0cz0bz0az0`z0_z0Z\ z0Yz0Xz0Wz0Vz0Uz0Tz0Sz0Rz0Qz0Pz0Oz0Nz0Mz0Lz0Kz0Jz0Iz0Hz0Gz0Fz0Ez0Dz0Cz0B\ z0Az09z08z07z06z05z04z03z02z01z00z00z03z07z0Bz0Fz0Jz0Nz0Rz0Vz0Zz0bz0fz0j\ z0nz0rz0vz0uz1tz1sz2rz3pz3oz4nz5mz5kz6jz7iz7hz8gz9ez9dzAczBbzB`zC_zDZzDY\ zEWzFVzFUzGTzHSzHQzIPzJOzJNzKLzLKzLJzMIzNGzNFzOEzPDzPCzQAzR9zR8zS7zT5zT4\ zU3zV2zW0zW0zV0yV0xU0wU0vT0uT0tS0sS0rR0qR0pQ0oQ0nP0mP0lO0kO0jN0iN0hM0gM0\ fL0eL0dK0cK0bJ0aJ0`I0_I0ZH0YH0XG0WG0VF0UF0TE0SE0RD0QD0PC0OC0NB0MB0LA0KA0\ J90I90H80G80F70E70D60C60B50A509408407306305204203102101 } frm:SuperNuker {; Justin Kolodziej ; mod. of Mr. Newstead's Nuke1 z = 0 c = pixel d = fn2(pixel): z = (fn1(z)+c)/d }
Does anyone else get a black image from this parset? I get a black image in xfractint. -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download <http://legalizeadulthood.wordpress.com/the-direct3d-graphics-pipeline/> Legalize Adulthood! <http://legalizeadulthood.wordpress.com>
Richard wrote:
Roger Alexander writes:
fract437.gif { ; almost a minibrot ; calctime 0:03:58.87
Does anyone else get a black image from this parset? I get a black image in xfractint.
Works fine in the REAL and classic FractInt. :-) Sincerely, P.N.L. -------------------------------------- http://www.Nahee.com/PNL/Fractals.html http://www.Nahee.com/Fractals/
Fracton gets a black screen also. This formula has no bailout test. When there is no bailout test in a formula, what does FractInt use? -- Mike Frazier www.fracton.org
I experimented with the formula until I found some bailout tests that give the correct image. The following all work in Fracton: | z | != 0 | z | > 0 abs( z ) != 0 abs( z ) > 0 The next one generated an image that is correct except for a few thin tendrils inside the brot. I think it is because of negative 0. z != 0 -- Mike Frazier www.fracton.org
In article <AANLkTiki7c8Fp2TsJURdrV3m-kPYh6oD=d3zrfwbtddm@mail.gmail.com>, Mike Frazier <fractonorg@gmail.com> writes:
This formula has no bailout test. When there is no bailout test in a formula, what does FractInt use?
I noticed that too after I reposted the parset. I think this is another case of the C code for the parser in xfractint differing from the assembly code. Jonathan can tell us for certain what the assembly formula parser uses when no bailout test is specified, but I'd guess its |z| > 0. -- "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,
Jonathan can tell us for certain what the assembly formula parser uses when no bailout test is specified, but I'd guess its |z| > 0.
Sorry, I can't. The bailout occurs when the AX cpu register is non-zero at the end of the iteration. But the fpu is being used for all the calculations. Since there is no test condition, there is no code that sets AX for bailing out. The only way to find out any more about what is happening is to compile the parser with the debug messages turned on. Unfortunately, this is no longer possible under DOS due to lack of memory. Jonathan
In article <1285724358.1713.11.camel@jonathan-desktop>, Jonathan Osuch <osuchj@avalon.net> writes:
Rich,
Jonathan can tell us for certain what the assembly formula parser uses when no bailout test is specified, but I'd guess its |z| > 0.
Sorry, I can't. [...]
Bummer. I just made it use |z| > 0 since that gave a comparable image in this case :-). -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download <http://legalizeadulthood.wordpress.com/the-direct3d-graphics-pipeline/> Legalize Adulthood! <http://legalizeadulthood.wordpress.com>
The bailout occurs when the AX cpu register is non-zero at the end of the iteration.
The last thing the parser did was calculate z. That sounds like it could be z != 0. That one also gives the correct image if you filter out the negative zeros. Maybe the FPU doesn't have those. I made Fracton use |z| > 0 so I will be the same as xFractInt. -- Mike Frazier www.fracton.org
Jonathan Osuch wrote:
The only way to find out any more about what is happening is to compile the parser with the debug messages turned on. Unfortunately, this is no longer possible under DOS due to lack of memory.
Not sure I understand exactly why (in details) that it may not be compiled under DOS any longer. Mike Frazier wrote:
The last thing the parser did was calculate z. That sounds like it could be z != 0. That one also gives the correct image if you filter out the negative zeros. Maybe the FPU doesn't have those.
This is quite likely and the most logical conclusion in my experience. I remember way back when, while still programming on main frames, that some compilers would allow both positive and negative zeros. At least until they were later modified in future releases to having only one possible signed value for a zero. Sincerely, P.N.L. -------------------------------------- http://www.Nahee.com/PNL/Fractals.html http://www.Nahee.com/Fractals/
This is quite likely and the most logical conclusion in my experience. I remember way back when, while still programming on main frames, that some compilers would allow both positive and negative zeros. At least until they were later modified in future releases to having only one possible signed value for a zero.
The positive and negative zeros are generated by the floating point hardware. They are required to be there to be compatible with the current standard for floating point. I always thought it was just an artifact that made designing the floating point hardware simpler. Apparently, they are useful in rounding and limits. There is a very good Wikipedia page on this at: http://en.wikipedia.org/wiki/Negative_zero This almost never matters because both flavors of zero give the same answer. The one case that does matter is comparing a floating point number to zero. Some compilers add extra code you can't see to make sure both zeros compare and some don't. This is yet one more challenge in trying to emulate the original DOS FractInt. -- Mike Frazier www.fracton.org
Paul,
Not sure I understand exactly why (in details) that it may not be compiled under DOS any longer.
Because Fractint is compiled using the Medium Memory Model which has a 64K Byte limit on data. We have been near this limit for many years. Enabling the debug messages for the fast parser puts us over the limit. It is not a simple matter to change the memory model. Doing so affects the interface to all the assembly code. Jonathan
participants (5)
-
Jonathan Osuch -
Mike Frazier -
Paul N. Lee -
Richard -
Roger Alexander