Orbit Fractals with an Arbitrary Formula
Is it possible to get fractint to plot these and if so how? Fractint seems to have specialized orbit types like the Henon attractor, but I want to specify the formula. IOW the "formula" type iterates over the screen pixels in an orderly gridlike fashion, but I want to go from pixel to pixel by iterating Pixel_new = F (Pixel_old) and mark the pixel each time. I found this process that seems to generate continuous(with sufficient iteration) fractal curves that look like wads of string with knots in random places (with greater iteration count, the large-scale length of the curve grows, but less than proportional to the number of iterations, and backfilling occurs at the same time at seemingly random locations so the curve is probably dense): x(n) = summation[m=1 to n]( sin(f(n)) * n^-a) y(n) = summation[m=1 to n]( cos(f(n)) *n^-a) where a is a constant between 0 and 1. One f that gives a fractal curve (briefly described above) is sqr, while f=log gives a smooth spiral. I'd like to plot these with fractint which has deep zooming capabilities, instead of the program I used which does not, and which failed at around 40000 iterated points. I know about the orbit screen in fractint, but it seems to me that if I use that with a "formula" type it will run the hundreds of thousands of iterations for every single pixel of the screen until the maximum iteration count is hit. That would take much too long. Is there some arcane .par magic to get fractint to display an orbit generated from only one point instead of the main screen? Hiram Berry
Hiram... Did you ever get an answer? I too am interested in plotting orbits. Kent Watring ----- Original Message ----- From: Hiram Berry To: Fractint and General Fractals Discussion Sent: Monday, March 01, 2004 7:03 PM Subject: [Fractint] Orbit Fractals with an Arbitrary Formula Is it possible to get fractint to plot these and if so how? Fractint seems to have specialized orbit types like the Henon attractor, but I want to specify the formula. IOW the "formula" type iterates over the screen pixels in an orderly gridlike fashion, but I want to go from pixel to pixel by iterating Pixel_new = F (Pixel_old) and mark the pixel each time. I found this process that seems to generate continuous(with sufficient iteration) fractal curves that look like wads of string with knots in random places (with greater iteration count, the large-scale length of the curve grows, but less than proportional to the number of iterations, and backfilling occurs at the same time at seemingly random locations so the curve is probably dense): x(n) = summation[m=1 to n]( sin(f(n)) * n^-a) y(n) = summation[m=1 to n]( cos(f(n)) *n^-a) where a is a constant between 0 and 1. One f that gives a fractal curve (briefly described above) is sqr, while f=log gives a smooth spiral. I'd like to plot these with fractint which has deep zooming capabilities, instead of the program I used which does not, and which failed at around 40000 iterated points. I know about the orbit screen in fractint, but it seems to me that if I use that with a "formula" type it will run the hundreds of thousands of iterations for every single pixel of the screen until the maximum iteration count is hit. That would take much too long. Is there some arcane .par magic to get fractint to display an orbit generated from only one point instead of the main screen? Hiram Berry ------------------------------------------------------------------------------ _______________________________________________ Fractint mailing list Fractint@mailman.xmission.com http://mailman.xmission.com/cgi-bin/mailman/listinfo/fractint
With some of the recent postings of various links around the Internet, does anybody know anything about the following: http://www.quickerwit.com/links/112735.htm Sincerely, P.N.L. ------------------------------------------------- http://home.att.net/~Paul.N.Lee/PNL_Fractals.html http://www.Nahee.com/Fractals/
Paul, - With some of the recent postings of various links - around the Internet, does anybody know anything about - the following: - - http://www.quickerwit.com/links/112735.htm It seems to be talking about a PDSL CD, which I've seen floating around for a nominal fee. According to the "Conditions on Use" section of the online documentation, "A nominal distribution fee may be charged for media and handling by freeware and shareware distributors." As to whether PDSL is a respectable outfit or not, I cannot say; but I did find some information about them on their site (www.pdsl.com) along with their claim that they've been distributing software since 1983. / Damien M. Jones http://www.fractalus.com/gallery/ \\ dmj@fractalus.com (personal gallery of fractal art) /
On 7 Mar 04, at 21:45, Damien M. Jones wrote:
Paul,
- With some of the recent postings of various links - around the Internet, does anybody know anything about - the following: - - http://www.quickerwit.com/links/112735.htm
It seems to be talking about a PDSL CD, which I've seen floating around for a nominal fee. According to the "Conditions on Use" section of the online documentation, "A nominal distribution fee may be charged for media and handling by freeware and shareware distributors."
As to whether PDSL is a respectable outfit or not, I cannot say; but I did find some information about them on their site (www.pdsl.com) along with their claim that they've been distributing software since 1983.
I can come pretty close to verifying that claim. When I was recently cleaning out 5.25" floppy disks, I found disks we had bought from PDSL in 1984. I recall that they were a good, reputable outfit. David gnome@hawaii.rr.com
Kent, No, I didn't get a direct answer concerning orbit fractals via the formula parser. However I think Gerald may have indirectly pointed out a way to do this in his message about per-image variable initialization. He pointed out that if one is careful with the comparison expressions, it is possible to cause an action based on an exact pixel value ( IF (real(z)==N && image(z)==M)...) For a suitable (N,M) value, that might never be invoked anywhere on the screen. So, in principle we ought to be able to have dual execution paths within the .frm, the unrelated one used to generate the main screen, and a separate one for generating the orbit. It would be invoked by calling up the <o> screen, then its subsidiary <p> toggle (direct numeric input), where one enters the (N,M) trigger that causes the orbit to be drawn. I say, "in principle", because I tried this in the following .frm, but could not get anything to display on the orbit screen (However, the main screen fractal with associated formula (it was the formula used for successive summation, but without doing the sums) was visually interesting, so I include it.). I would like to know why I didn't get the expected results on the orbit screen, so if you've an idea why not, please let me know. Sincerely, Hiram /************FRM for orbit generation*********************************/ XY_Orbiter_1 { ; INITIALIZE: fn1=sqr,fn2=sin,fn3=cos,p1=(10000,0),p2=(-0.05,0) ; ORBIT SCREEN FLAG: <p> toggle values (999,999) ; generates orbits on the <o> screen for a summation process ; x(n) = summation[m=1..n](fn2(fn1(n)*m^a) ; y(n) = summation[m=1..n](fn3(fn1(n)*m^a) ; The {fn2,fn3} ought to be an associated pair like {cosine,sine} ; The main screen is extraneously the Mandeloid of the function summed. ; Iteration count for the orbit is to be put in p1.real ; a is specified in p2.real ; Trigger orbit by <o> then <p> to get the numbers screen, where enter ; values "999" twice to generate the orbit IF (initflag == 0) a = p2, initflag = 1, isorbit = 0, isntorbit = 1 iterhold = maxit ENDIF IF (real(scrnpix) == 999 && imag(scrnpix) == 999) ; orbit screen init iterhold = maxit, maxit = p1, isorbit = 1, isntorbit = 0, z = (0,0) ELSE ; nonorbit (main screen) init isorbit = 0, isntorbit = 1, z = pixel maxit = iterhold ENDIF : IF (isorbit) z = z + real(fn2(fn1(z)*z^a)) + flip(real(fn3(fn1(z)*z^a))) ELSE z = real(fn2(fn1(z)*z^a)) + flip(real(fn3(fn1(z)*z^a))) ENDIF ( isorbit && ( |z| < 1E20 ) ) || (isntorbit && ( |z| < 4 + p3 ) ) } /**************FRM END**********************************************/ /********************PAR BEGIN-main screen generates interesting artifact********/ Fossil_1 { ; Fractint Version 2003 Patchlevel 1 reset=2003 type=formula formulafile=exprmntl.frm formulaname=XY_Orbiter_1 function=sqr/sin/cos passes=1 center-mag=0.064994/-1.89372/0.8259203/1/90/-1.23373533611470521e-014 params=10000/0/0.05/0/1000/0 float=y maxiter=2000 inside=fmod logmap=4 colors=000eee0000e0Ug4xi8oY4eL0<2>SSLllLssLzzLzzz000555<3>HHHKKKOOO<3>cc\ chhhmmmsssU0cxzw<3>xjUxfNxbFxi8wU0<4>ZfQUiV0e0Koe<3>0zz<2>0Gz<3>rVzzVzzV\ rzVjB`0zVV<3>zzV<3>VzV<3>VzzVrzVjzLW0hhz<3>zhz<3>zhh<3>zzhvzhqzhWQ0hzh<2\
hzvm00xi8hqzhlz00S<3>S0SS0LS0EeL0000S70<2>SS0<3>0S0<3>0SS0LS0ESeee000IE\ S<2>SES<3>SEE<3>SSEPSELSELLL000ESI<2>ESS<2>EHSKKS<2>QKSSKSSKQSKOSSL000SM\ KSOKSQKSSK<2>MSKKSKKSMKSOKSQKSSKQSKOSZZL000<4>EE7HH8JJ9MMBPPC<3>__IbbKee\ L000<4>GG7JJ8NN9QQBTTC<3>eeIiiKllL000<4>II7MM8QQ9TTBXXC<3>llIooKssL000<4\ LL7PP8TT9XXB``C<3>rrIvvKzzL000<3>JJJOOOSSS<6>zzz000zzzm00 } /***************************PAR END***********************************/
I'm sure you guys are welcome to write some parser code that lets you make assignments to X and Y of pixel. I figure if FRACTINT detects that they've changed, then it can also check if they're bounded by the screen. Perhaps color could be assignable in an effective way, too --when it's assigned, then that's the point of escape.
Hiram Berry wrote:
Is it possible to get fractint to plot these and if so how?
Apologies to you and Kent Watring for not answering at all, the postings of both of you somehow "evaporated" from my memory! There are, IMHO, two possible approaches to rendering orbit formulas, that is, something like x(n+1) = f(x(n),y(n)), y(n+1) = g(x(n),y(n)). Method A: Convert the orbit formula into an escape time one by checking if one of the orbit points has hit a pixel. One only needs to specify a small epsilon around each pixel and bail out when an orbit point falls within the limit. The last lines of such formula would look like ... z = x + flip(y) |z-pixel| < eps } There's a drawback, though. Orbit fractals normally need thousands of plotted points to produce a decent image - and we would have to run the whole orbit *for each pixel* just waiting for the pixel to get hit once! And there would be no shortcuts to speed up rendering - we'd need to check every single pixel! Talk about patience :-) Method B: As you have suggested - using the Orbit Window. (*Not* the orbit display accessed by pressing <o> while the fractal is running - this one displays the orbits of every pixel of the screen. The Orbit Window is opened with either the <o> key after the fractal has finished or by using <Ctrl>+<o> while the fractal is running.) BTW one should set a small view window for the main display via the <v>-screen to let the Orbit Window have the whole screen's "real estate" (and it's a good idea to get acquainted with the OW controls, which are different from those of the main fractal display). Considerations for the formula itself: Besides of a big number of points to plot (easy, just crank up the iteration count on the <x>-screen) and switching off periodicity-checking (just to be on the safe side), we need a formula which hands the orbit point coordinates back to Fractint and which doesn't bail out early - again easy, put those coordinates into the variable "z" and close the formula with a final check that never is false, like ... variable-name == variable-name } And that's all! Two pars + formulas appended (...your formula indeed produces strange and beautiful images). Regards, Gerald ;----------------------- PARs following ----------------------- Lauwerier { ;Press <Ctrl>+<o> after loading ; reset=2003 type=formula formulafile=gkd.frm formulaname=oLauwerier corners=-2/2/-1.5/1.5 params=3/2/0.1/0.1 float=y maxiter=100000000 periodicity=0 viewwindows=4.2/0.75/yes/0/0 colors=@firestrm.map } Hiram { ;Press <Ctrl>+<o> after loading, <,> to zoom out! ; reset=2003 type=formula formulafile=gkd.frm formulaname=oHiram function=sqr corners=-2/2/-1.5/1.5 params=0.5/0 float=y maxiter=10000000 periodicity=0 viewwindows=4.2/0.75/yes/0/0 colors=@firestrm.map } frm:oLauwerier {;from "Algorithmen fuer Chaos und Fraktale", ;p.131 ;--------------- ; p1real = a ; p1imag = b ; p2real = x(0) ; p2imag = y(0) ;--------------- a = real(p1), b = imag(p1) x = real(p2), y = imag(p2): tmp = y y = x + y*(a*x-1-b*y) x = tmp z = x + flip(y) tmp == tmp } frm:oHiram { ;------------------- ; p1real = a (0<a<1) ;------------------- a = real(p1) x = y = n = 0: n = n + 1 x = x + sin(fn1(n))/n^a y = y + cos(fn1(n))/n^a z = x + flip(y) n == n } ;------------------------ End of PARs -------------------------
Maybe you want a passes method that iterates every pixel once per pass over the screen. IOW, it would probably need enough memory to represent the screen in the form of suspended calls to the formula -- which is doable in computers less than five years old. On Thu, 11 Mar 2004, Gerald K. Dobiasovsky wrote: (...)
There's a drawback, though. Orbit fractals normally need thousands of plotted points to produce a decent image - and we would have to run the whole orbit *for each pixel* just waiting for the pixel to get hit once! And there would be no shortcuts to speed up rendering - we'd need to check every single pixel! Talk about patience :-) (...)
participants (7)
-
Damien M. Jones -
David Jones -
Gerald K. Dobiasovsky -
Hiram Berry -
Kent Watring -
Paul N. Lee -
SherLok Merfy