At 18:00 25/05/2002, Gerald K. Dobiasovsky wrote:
From: "Morgan L. Owens" Sent: Thursday, May 23, 2002 3:19 PM
At 00:19 24/05/2002, Morgan L. Owens wrote:
4movable{
Oh, that's right; the current (developer) version has 5 user pars.
[Big intricate formula snipped...]
To be honest, that larger one is actually known to be broken - the code only still only checks the tangency of four circles (notes for which are in the original version). Position circles at (-1,+/-0.1), (0,+/-0.2) and (2,0) to see what I mean - the one on the right should be much bigger. To confess further, I've found situations where the original four-circle code fails to ensure proper tangency. But it was painful enough getting it into the state it's in now: while I was writing it I perpetually found myself wishing I could use arrays and nested loops. And a debugger.
Not feeling capable to code something which will evoke headlines like "script for freeware fractal software beats Mathematica - Wolfram says he's stunned"
Some earlier attempts of mine broke Fractint. "Too many jumps" it said... And one more confession. I could have made them twice as fast, and my own personal copies do. The problem is that they achieve their speedup by means of a hack that relies on something which I consider to be a bug (or rather, enhancement opportunity) in the Fractint formula parser. The "bug" is that values computed for one pixel are still retained when the next pixel is calculated. Now, if you were behaving yourself in the first place, you would have set the values of any variables you used in the formula, so that in the second pixel they'd be recalculated all over again. But if you _use_ a variable _before_ giving it a value, then for the first pixel it will have a value of zero, while for subsequent pixels it will have whatever you set it to during calculation of the previous pixel. The problem is that the order in which pixels are calculated depends critically on the drawing method used. The following formula and par SHOULD NOT work: swatch { ; Version 2001 Patchlevel 8 reset=2001 type=formula formulafile=swatch.frm formulaname=swatch passes=1 center-mag=0/0/0.6666667/1.3333 float=y maxiter=256 inside=255 periodicity=0 viewwindows=1/1/yes/256/256 colors=000ccc<3>nnnqqqtttwwwzzz<4>IIz99z00z<9>bbOffKjjG<3>zz0<9>zO0zK0zG\ 0<3>z00<9>O0bK0fG0j<3>00z<9>0bO0fK0jG<3>0z0<9>bObfKfjGj<3>z0z<9>`0`Y0YV0\ V<2>N0NK0KJ1L<8>8Ia7Kc5Me<2>2Sk0Um0Vm<8>0em0fm0hm<2>0km0mm0mm<8>0gu0gu0f\ v<3>0cz<9>bqzfrzjtz<3>zzz<25>zhCzgAzf8<2>zd2zc0zd0<8>zq0zr0zt0<3>zz0<9>z\ O0zK0zG0<3>z00<14>ZZZ } frm:swatch{ z=ig ig=ig+1 if(ig==256) ig=0 endif : z=z-1 z } And it won't if you use any drawing method other than (1) or (b). So what? What has this conversational tangent got to tangential circles? In the 4movable and 5movable (and I really should have thought of better names than those) formulae, virtually _all_ the initialisation is identical for every single pixel - the only pixel-dependent initialisation is the line "z=pixel". If I could retain from one pixel to the next those radii that the code goes to such great lengths to compute I would get a huge speedup. And this is how I do it: Insert as the first line of the initialisation the line if(precalc==0) I've yet to say what value "precalc" actually has yet: for the first pixel computed it will be zero (and so the test will succeed); for subsequent pixels it will be whatever the previous pixel set it to, which is done by adding endif precalc=1 immediately before the "z=pixel" line. So when the first pixel is initialised, precalc==0, and so all the radius calculation is carried out. Afterwards, precalc==1, so all that work is skipped, the values of r1..r4 are never overwritten and so retain their values set when the first pixel was initialised. It's a good thing that none of that initialisation did use pixel-specific quantities or this would obviously never have worked. The Opportunity. The above is a dirty hack. One should instead have a per-image initialisation section in Fractint formulae just as there is now for per-pixel initialisation. A backwards-compatible syntax would be: formulaname{ per-image initialisation code :: per-pixel initialisation code : per-iteration code } After getting that off my chest I'm finally going to let myself have a look at these new pars! Morgan "She Speeds"