The orbits.par file has some examples of what the new passes=o feature can do. For those of you missing the orbits.par file, which would be anybody that didn't download the dif file, here it is: demonic_moose { ; Jonathan Osuch josuch@fractint.org reset=2004 type=tetrate passes=o center-mag=0.325467/4.44089e-16/0.5788618/1/-90/3.88578058618804789e-16 params=0/0 float=y inside=0 outside=summ orbitdelay=30 orbitinterval=5 colors=000FFF<24>p33r33s22<2>x11z00z10<24>zn0zp0zr0<2>zx0zz0zz1<24>zznzz\ pzzr<2>zzxzzzzzz<57>zX5zX4zW3zW2zV1<27>z50z40z30z20z10z00<28>f00e00d00<3\ 1>FFF } space_debris { ; Jonathan Osuch josuch@fractint.org reset=2004 type=mandelfn function=sin passes=o center-mag=-3.9968e-15/3.10862e-15/0.3360215 params=0/0 float=y inside=0 outside=summ orbitdelay=40 colors=000FFF<24>p33r33s22<2>x11z00z10<24>zn0zp0zr0<2>zx0zz0zz1<24>zznzz\ pzzr<2>zzxzzzzzz<57>zX5zX4zW3zW2zV1<27>z50z40z30z20z10z00<28>f00e00d00<3\ 1>FFF } solar_flares { ; Jonathan Osuch josuch@fractint.org reset=2004 type=fn(z)+fn(pix) function=recip/sqr passes=o center-mag=-1.55431e-15/1.11022e-15/0.613196 params=0/0/1/0 float=y inside=0 outside=summ orbitdelay=50 orbitinterval=7 colors=000FFF<24>p33r33s22<2>x11z00z10<24>zn0zp0zr0<2>zx0zz0zz1<24>zznzz\ pzzr<2>zzxzzzzzz<57>zX5zX4zW3zW2zV1<27>z50z40z30z20z10z00<28>f00e00d00<3\ 1>FFF } spaghetti { ; Jonathan Osuch josuch@fractint.org reset=2004 type=mandel passes=o center-mag=-0.116813/0.0273794/2.73224 params=0/0 float=y inside=0 colors=00000z<3>00i00a<3>00L00H00D<2>000<10>d0Lg0Nk0P<3>z0Xv0Vr0Tp0Sn0R<\ 6>O0CK0AG08<3>000<9>X0a_0dc0h<3>p0w<9>K0NH0JD0F<3>000<9>bbbfffjjj<3>zzz<\ 9>OOOKKKGGG<3>000L00<8>k00<4>z00<2>p00l00h00d00a00<3>N00J00F00<3>000<9>b\ L0fN0jP0<3>zX0<9>OC0KA0G80<3>000<9>__0cb0gf0<3>ut0<9>ML0II0FE0<3>000GA4<\ 7>7c26g25k2<2>2v10z00w0<8>0O00K00G0<3>000<14>00v }
comment { On Sat, 13 Nov 2004, Jonathan Osuch wrote:
The orbits.par file has some examples of what the new passes=o feature can do.
orbitdelay=30 orbitinterval=5
I hope that both of these end up on the screen for sound parameters and that "passes=o" has something going for it beyond "showorbit=yes". The orbitinterval, if it skips some of the orbits, would add a feature that is in a program for sound from fractals that some guy from RoadRunner-Hawaii mentioned recently, but I suspect that it actually specifies how many orbits to keep on the screen at once. Understanding this code might bring you to a feature I wanted in orbits that can be connected with any escape-time fractal to make queerly arcade-like sounds on a 486. It is perhaps something that can be done with /dev/dsp or sox. _______ } Fireworks { ; Anybody got a better way to see only the orbits? ; Symmetry assertion doesn't work at this angle. ; Fractint Version 2003 Patchlevel 1 reset=2003 type=formula formulafile=fire.par formulaname=mandelbroh function=ident/conj passes=t center-mag=-0.455826/0/0.6835187/1.181/90/3.88578058618804789e-016 params=-2/16 float=y maxiter=255 inside=255 proximity=-0.025 outside=fmod symmetry=xaxis periodicity=0 showorbit=yes colors=@altern.map } MandelBroh { z=fn1(pixel), c=fn2(pixel): z=z^real(P1) +c |z| <= imag(P1) }
"Jonathan Osuch" <osuchj@avalon.net> wrote, in part:
The orbits.par file has some examples of what the new passes=o feature can do.
Indeed! Very nice, Jonathan, and thanks for including this feature. I've wanted an easy way to look at the combined set of attractor orbits for the Mandelbrot set and similar Mandeloids in Fractint for some time now, and this seems to accomplish this. If I understand its operation correctly, it iterates through all points on the screen in row major sequence, plotting the z values on each iteration. Is the orbitdelay=n feature only accessible via text insertion in the relevant .par file? I don't see it as an option on the y-screen and inserting "orbitdelay=100" in the .frm seems to have no effect. Also, when using the outside=summ or inside=0 options for rendering, is the log palette translation available? One other question: I understand that the periodicity=0 option is supposed to not plot orbits that go off the screen or bailout. Is there any way to show, of those, only the ones with a certain value of periodicity? The reason I ask this is that such would be useful in looking at the order of plotting of points in the orbit in a Julia set, which I believe is supposed to be dependent on the position of its associated bud in M-set. Now it seems to me that iterating through all the screen pixel positions is of limited usefulness without some post processing-- I'd find it more insightful to iterate over a specifically bounded area and look at where the set of orbits is. Eg. draw around one minibrot, or the main body only, or just one bud, or the buds of only one value of periodicity, and see where the set of all orbits is. If the z values were based on the scrnpix variable instead of complex plane value, zooming in wouldn't change the image ( except periodicity=0 might not be usable here-- orbits that bounce around into areas offscreen wouldn't be shown if I understand correctly). The scrnpix values could be mapped onto the bounded area of interest before feeding the resultant z or C value to the iteration part. Alternately, we could just chuck the screen position completely and get the z or C randomly within the bounded area each pixel-pass. Which I attempted in the included .par and .frm. Strangely, however, even though periodicity=0 was in effect and MOST of the diverging orbits were culled out, some points outside the bailout circle radius 2 showed up on the screen anyway. I don't understand why that would happen. Some speculation on the orbits: in Mandelbrot-like escapetime fractals we are after all looking not really at the complex plane, but rather at the behavior of sequences indexed on the C-plane. Notice on the M-set that each bud has at most a single tangent point with any other bud. It seems likely to me that all sequences within a single bud are in some sense continuous in the same way that their representations on the C-plane are, ie. if we look at all the elements of 2 sequences whose C-plane indices differ by a vanishingly small differential value, all of the corresponding elements will not differ by a finite amount-- there never is a discontinuity no matter how far the sequences are iterated. I don't know if this is true or not, but if so it seems reasonable to look for something else. Consider that in the sequence z0 -> z1 -> z2 -> ... we could just shift all elements one place to the left and truncate z0. This new sequence has to have the same attractor as the original sequence since for most purposes it IS the same sequence. We could index the first one S(1) and the second one S(2), and succeeding ones S(n) n->inf all with the same attractor. But if natural numbers are valid indices for a family of sequences, what about fractional values? Is there an S(2.5)? What is a reasonable way to define fractional iteration, IOW is there a way to extend functional iteration analogous to the way the factorial function is extended to the gamma function? And of course, what does it mean to iterate a function an imaginary or complex number of times? What do the curves that represent such families look like within the buds of the M-set, and how do they relate to objects now viewable with the passes=o option in Fractint? ---Hiram INCOMPLETE FRM FOR USING TRANSLATED PIXEL AREAS WITH passes=o: +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ MJorbitalarea_rand{ ; use with "pass=o" option, periodicity=0, orbitdelay non0. ; starting pixels chosen from user-selected areas; p1 used for M/J toggle, ; p2=(bailout,areatype(0=square,1=circle,2=ring,3=cardioid,4=cardioid ring)), ; p3=key pt, p4=scale distance(complex vals rotate), p5=secondary dist(2,4). IF( init==0 ) ; per-screen initialization ismand = 1 bailout=real(p2),type=imag(p2),keypt=p3,scale=p4,t=p5 init = 1 orbitdelay = 100 ; does this work? ENDIF IF( type==0 ) ; pixel translation pixtrans = keypt + scale*rand ; random points on([0..1],[0..1] scaled ELSE ; implement other types here pixtrans = keypt + scale*rand ; STUB:change as appropriate ENDIF IF( ismand ) ; per-pixel initialization z = 0 C = pixtrans ELSE z = pixtrans C = p1 ENDIF : z = sqr(z) + C |z| <= bailout } ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ NOT VERY INTERESTING PAR USING IT: ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ testorbitparms { ; orbitdelay cannot be set from the frm or the y-screen reset=2004 type=formula formulafile=orbit.frm formulaname=mjorbitalarea_rand ismand=y passes=o center-mag=5.78e-006/-7.005e-006/0.6666636 params=0/0/4/0/-2/-2/4/0/0/0 float=y inside=0 outside=summ logmap=yes periodicity=0 cyclerange=1/253 orbitdelay=100; colors=@grad0054.map colors=000X3r<40>v16w15x14x13y12z00<42>ze0zf0zg0zh0zi0<2>zj0yj1yj1xk1xk2\ <71>WyUWyUVzV<43>VxtVxuVxuVxvUww<23>syytyyuyy<3>zzz000000 }+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
On Wednesday 17 November 2004 12:29 am, Hiram Berry wrote:
Indeed! Very nice, Jonathan, and thanks for including this feature. I've wanted an easy way to look at the combined set of attractor orbits for the Mandelbrot set and similar Mandeloids in Fractint for some time now, and this seems to accomplish this. If I understand its operation correctly, it iterates through all points on the screen in row major sequence, plotting the z values on each iteration.
Yes, that is correct.
Is the orbitdelay=n feature only accessible via text insertion in the relevant .par file? I don't see it as an option on the y-screen and inserting "orbitdelay=100" in the .frm seems to have no effect.
As you said, it would go in the PAR, not the FRM. The orbitdelay parameter is set on the Sound Control Screen in Fractint <cntl-F>, and the Basic Options screen in Xfractint <X>. Since we don't have the Sound Control Screen enabled in Xfractint, the orbitdelay setting has to be on another screen. The passes=o options can be put on a new screen. A reasonable and available key stroke would need to be determined.
Also, when using the outside=summ or inside=0 options for rendering, is the log palette translation available?
No, not at this time.
One other question: I understand that the periodicity=0 option is supposed to not plot orbits that go off the screen or bailout. Is there any way to show, of those, only the ones with a certain value of periodicity? The reason I ask this is that such would be useful in looking at the order of plotting of points in the orbit in a Julia set, which I believe is supposed to be dependent on the position of its associated bud in M-set.
It's the other way around, sort of. With periodicity=0, the iterations continue even when the orbits are off the screen. BTW, this isn't coded correctly since it requires both the x and y values to be off the screen to skip to the next pixel. If I fix it now, I'll have to add backwards compatibility. This also affects the 2D and 3D orbit calcs since I borrowed the logic from them. The inside=period option plots the period of inside points when periodicity checking is turned on. It looks to me like it doesn't work quite correctly because the color number doesn't match the number of actual attractors shown with the <o> option after the image is completed.
Now it seems to me that iterating through all the screen pixel positions is of limited usefulness without some post processing-- I'd find it more insightful to iterate over a specifically bounded area and look at where the set of orbits is. Eg. draw around one minibrot, or the main body only, or just one bud, or the buds of only one value of periodicity, and see where the set of all orbits is.
Use passes=g to zoom to a minibrot, then set passes=o and periodicity=0.
If the z values were based on the scrnpix variable instead of complex plane value, zooming in wouldn't change the image ( except periodicity=0 might not be usable here-- orbits that bounce around into areas offscreen wouldn't be shown if I understand correctly). The scrnpix values could be mapped onto the bounded area of interest before feeding the resultant z or C value to the iteration part.
Plotting, for example, X=0 to 799 and Y=0 to 599, would be very uninteresting. And, as you say, would be invariant upon zooming. I believe the mapping you suggest is exactly what currently is done.
Alternately, we could just chuck the screen position completely and get the z or C randomly within the bounded area each pixel-pass. Which I attempted in the included .par and .frm.
What would the resulting image represent?
Strangely, however, even though periodicity=0 was in effect and MOST of the diverging orbits were culled out, some points outside the bailout circle radius 2 showed up on the screen anyway. I don't understand why that would happen.
Periodicity=0 forces the iterations to continue even when both the X and Y cordinates of the orbit are off screen.
Some speculation on the orbits: in Mandelbrot-like escapetime fractals we are after all looking not really at the complex plane, but rather at the behavior of sequences indexed on the C-plane. Notice on the M-set that each bud has at most a single tangent point with any other bud. It seems likely to me that all sequences within a single bud are in some sense continuous in the same way that their representations on the C-plane are, ie. if we look at all the elements of 2 sequences whose C-plane indices differ by a vanishingly small differential value, all of the corresponding elements will not differ by a finite amount-- there never is a discontinuity no matter how far the sequences are iterated. I don't know if this is true or not, but if so it seems reasonable to look for something else. Consider that in the sequence z0 -> z1 -> z2 -> ... we could just shift all elements one place to the left and truncate z0. This new sequence has to have the same attractor as the original sequence since for most purposes it IS the same sequence. We could index the first one S(1) and the second one S(2), and succeeding ones S(n) n->inf all with the same attractor.
We use this concept for periodicity checking.
But if natural numbers are valid indices for a family of sequences, what about fractional values? Is there an S(2.5)? What is a reasonable way to define fractional iteration, IOW is there a way to extend functional iteration analogous to the way the factorial function is extended to the gamma function? And of course, what does it mean to iterate a function an imaginary or complex number of times? What do the curves that represent such families look like within the buds of the M-set, and how do they relate to objects now viewable with the passes=o option in Fractint?
That thought is beyond my meager capabilities. 8-)) Jonathan
Thanks, Jonathan, for the in depth discussion and clarification on how the passes=o feature works. [...snippage...]
One other question: I understand that the periodicity=0 option is supposed to not plot orbits that go off the screen or bailout. Is there any way to show, of those, only the ones with a certain value of periodicity? The reason I ask this is that such would be useful in looking at the order of plotting of points in the orbit in a Julia set, which I believe is supposed to be dependent on the position of its associated bud in M-set.
It's the other way around, sort of. With periodicity=0, the iterations continue even when the orbits are off the screen. BTW, this isn't coded correctly since it requires both the x and y values to be off the screen to skip to the next pixel. If I fix it now, I'll have to add backwards compatibility. This also affects the 2D and 3D orbit calcs since I borrowed the logic from them.
Ah! That fixes a lot of my consternation. As you note, I had it backwards... [...]
Now it seems to me that iterating through all the screen pixel positions is of limited usefulness without some post processing-- I'd find it more insightful to iterate over a specifically bounded area and look at where the set of orbits is. Eg. draw around one minibrot, or the main body only, or just one bud, or the buds of only one value of periodicity, and see where the set of all orbits is.
Use passes=g to zoom to a minibrot, then set passes=o and periodicity=0.
When we zoom in, though, the domain pixels (the parameter values used for the orbits) will be accordingly changed, right? What I want to do is to possibly get the domain values from a different area than what the screen is showing for the display range, without having to change parameters on the z-screen if a zoom is done. [...]
The scrnpix values could be mapped onto the bounded area of interest before feeding the resultant z or C value to the iteration part.
Plotting, for example, X=0 to 799 and Y=0 to 599, would be very uninteresting. And, as you say, would be invariant upon zooming. I believe the mapping you suggest is exactly what currently is done.
Yes, but that mapping is fixed to the screen rectangle. I'm suggesting the possibility, of say mapping scrnpix to the inside of the cardioid r=(1-cos(theta))/2 for example if we only want to see the orbits from the points originating on the period=1 cardioid of the M-set.
Alternately, we could just chuck the screen position completely and get the z or C randomly within the bounded area each pixel-pass. Which I attempted in the included .par and .frm.
What would the resulting image represent?
Admittedly the example I showed yesterday wasn't very clear. The random number on a domain area doesn't seem to give much resolution to the image. The point I was trying to make is that the area and form of the concatenated orbit set may not be in the same area as the generating domain set, so there is a catch: if the screen shows the domain area, it might not show some of the resultant range area, and if I enable periodicity=nonzero many of the orbits will go offscreen at some point even though they are valid attractors, while if I make periodicity=0 a lot of noise gets displayed along with the target set. Now that I think about it, using a proxy for 'z' in the iteration and then setting z=zprox if I want to show it, or z=<an offscreen point> otherwise might solve this dilemma. Here's a more interesting example of why I want to choose the domain points separately from the screen coordinates. They're taken just from a diagonal line through the M-set-- but watch the evolution of the image... not nearly as simple as one might expect! The apparent trajectories look almost like they obey physical laws of nature as they are laid down, and the final image looks very like a complicated cloud chamber image of particle interactions! ---Hiram /* FRM: */ MJorbit_rectarray{ ; rectangular or line segment domain for orbits z->z^n+C ; use "pass=o" option, periodicity=0, orbitdelay nonzero. ; p1 used for M/J toggling,p2=(n(int>1),bailout),p3=endpt1,p4=endpt2, ; p5=width(real==0 = line segment) IF( init==0 ) ; per-screen initialization ismand = 1 n=floor(real(p2)),bailout=abs(imag(p2)),e1=p3,e2=p4,w=p5 IF(n<2), n=2, ENDIF IF(bailout==0), bailout=sqr(n), ENDIF seg = ( real(w)==0 ) xmax = real(scrnmax), ymax = imag(scrnmax) v = e2 - e1, pts = xmax*ymax, len = cabs(v), wid = real(w), A = len*wid IF( seg ) subdiv = pts-1 ELSE norm = flip(conj(v/len)), u = norm * w, start = e1 - u/2 rows = floor(sqrt( wid*pts/len ) ) cols = floor(pts/rows), subdiv = rows*cols ENDIF init = 1 ENDIF ptct = imag(scrnpix)*xmax + real(scrnpix) IF(seg) ; line segment domain sample pixtrans = e1 + v * ptct/subdiv ELSE ; rectangle or parallelogram domain sample col = floor(ptct/rows), row = ptct-rows*col pixtrans = start + col/(cols-1)*v + row/(rows-1)*u ENDIF IF( ismand ) z = 0 C = pixtrans ELSE z = pixtrans C = p1 ENDIF : z = z^n + C |z| <= bailout } /* PAR: */ WiresOfCreation { reset=2004 type=formula formulafile=orbit.frm formulaname=MJorbit_rectarray ismand=y passes=o center-mag=0.0448761/-7.005e-006/0.3338125 params=0/0/2/4/-2/-2/2/2/0/0 float=y maxiter=1000 outside=summ periodicity=0 cyclerange=1/1 orbitdelay=900; colors=@grad0056.map colors=000nSYpPR<5>oaRocRnfR<2>nlRmoRloS<3>eo_coaaod<3>SpnQppQpp<31>NqqN\ qqNqq<2>MrrMrrLqr<58>1Xk1Xk0Wj<29>0Wq0Wq0Wr<87>`Ly`LyaLy<3>cKz00Racz }
On Thursday 18 November 2004 12:58 am, Hiram Berry wrote: [snipped]
When we zoom in, though, the domain pixels (the parameter values used for the orbits) will be accordingly changed, right? What I want to do is to possibly get the domain values from a different area than what the screen is showing for the display range, without having to change parameters on the z-screen if a zoom is done.
Ah, the light comes on! Would using the default coordinates for each fractal type be acceptable? Alternatively, I am planning to add a <cntl-p> screen with passes options on it and default coordinates could be on it. Possibly just an X and Y value, and then show -X to +X and -Y to +Y on the screen. The first option is preferable from an impementation standpoint since it wouldn't involve adding additional parameters to PARs and GIFs. I've already done it in my version, and it does prevent rotating the image, as was done with the Demonic_Moose image.
Yes, but that mapping is fixed to the screen rectangle. I'm suggesting the possibility, of say mapping scrnpix to the inside of the cardioid r=(1-cos(theta))/2 for example if we only want to see the orbits from the points originating on the period=1 cardioid of the M-set.
So, instead of plotting: for (row=0, row<ydots, row++) for (col=0, col<xdots, col++) we could plot: for (theta=0, theta<360, theta++) Or something similar.
Here's a more interesting example of why I want to choose the domain points separately from the screen coordinates. They're taken just from a diagonal line through the M-set-- but watch the evolution of the image... not nearly as simple as one might expect! The apparent trajectories look almost like they obey physical laws of nature as they are laid down, and the final image looks very like a complicated cloud chamber image of particle interactions!
Hmm, that is interesting. Jonathan
Jonathan Osuch wrote: <snip>
So, instead of plotting: for (row=0, row<ydots, row++) for (col=0, col<xdots, col++)
we could plot: for (theta=0, theta<360, theta++)
Or something similar.
<snip> Back in th 1980s I wrote a program that drew some very nice pictures similar to these ideas. you need: starting x and y ending x and y number of points in between number of iterations at each point. I also had the colour changing for each iteration at the point. If someone would add this to fractint I am sure that it would be a hit. If you choose the line properly you get very stunning pictures. Doug Stewart
On Thursday 18 November 2004 10:21 am, doug Stewart wrote:
Back in th 1980s I wrote a program that drew some very nice pictures similar to these ideas. you need: starting x and y ending x and y number of points in between number of iterations at each point. I also had the colour changing for each iteration at the point. If someone would add this to fractint I am sure that it would be a hit.
If you choose the line properly you get very stunning pictures.
That is an interesting idea. Taken with some of Hiram's comments, we may be getting out of the realm of a passes option. We would need to implement something like what was done with the julibrot type. I'll have to give that some thought. Jonathan
Jonathan Osuch <osuchj@avalon.net> wrote: [...]
That is an interesting idea. Taken with some of Hiram's comments, we may be getting out of the realm of a passes option. We would need to implement something like what was done with the julibrot type. I'll have to give that some thought.
I have a strong hunch that you are right about this. In particular, the M-set's image appears to be an object in its own right, looking very different from the M-set itself. If you take the M-set on one C-plane as the domain, and the orbits on an orthogonal complex dimension as the range... the image is shown fully shown as a surface in this CxC space-- just like the Julibrot! Now how to generate a perspective of this in 2-D or simulated 3-D... you'd almost certainly need to do the SAME procedure as with the Julibrot. I'd sure like to know what it looks like though, and if it's possible to plot geodesic curves on it. ---Hiram
Doug Stewart <Dastew@sympatico.ca> wrote: To: "Fractint and General Fractals Discussion" <fractint@mailman.xmission.com>
Jonathan Osuch wrote: <snip>
So, instead of plotting: for (row=0, row<ydots, row++) for (col=0, col<xdots, col++)
we could plot: for (theta=0, theta<360, theta++) Or something similar.
<snip> Back in th 1980s I wrote a program that drew some very nice pictures similar to these ideas. you need: starting x and y ending x and y number of points in between number of iterations at each point. I also had the colour changing for each iteration at the point. If someone would add this to fractint I am sure that it would be a hit.
If you choose the line properly you get very stunning pictures.
Right you are, Doug. Take a look at the image generated from the included FRM and PAR. These simply draw a pentacle through the main cardioid of the M-set with corners at the 0,1/5,etc. bud tangencies, and then render the points using the passes=o. I didn't have any idea that a "knot" of such complexity could result from such a simple shape! Do you remember the settings or general algorithm you used in your program? I am very interested in these slices of the M-set orbit image object, and if you would share your experience with these I'm sure others would appreciate it as well. ---Hiram /* PAR: Flower_Antiflower */ Flower_Antiflower { ; ;HiramBerry;1280x1024 with maxit-orbitdelay=100;resolut ; ion affects color with passes=o,outside=summ, so adjust ; difference according to density, eg. maxit-delay=56 for ; 1024x768 or 37 for 800x600. reset=2004 type=formula formulafile=orbit.frm formulaname=morbcardpentanglin passes=o center-mag=0.103851/-0.0106518/1.315817/1/-90/3.88578058618804789e-016 params=0/1/1/5/2/5/3/5/4/5 float=y maxiter=300 inside=0 outside=summ periodicity=0 cyclerange=1/1 orbitdelay=200 colors=mmwxZU<5>_NHVLFRJDMHBIF9<3>070<108>0x00x00y00y00z0<126>000 } /* FRM: Morbcardpentanglin */ Morbcardpentanglin{ ;HiramBerry; passes=o,orbitdelay=nonzero. Domain points ; drawn from the segments connecting the vertices of a pentacle, iterating ; from them. Iteration is Mandelbrot style,p[1..5]=vertex[1..5],no z-perturb, ; vertices specified by (increment(int),period(int)) point on main cardioid. IF(initialized==0) initialized=1 rays=10 cols=real(scrnmax),rows=imag(scrnmax),pts=cols*rows rctx2=floor(pts/rays)*2 theta1=2*pi*real(p1)/imag(p1),rad1=(1-cos(theta1))/2 theta2=2*pi*real(p2)/imag(p2),rad2=(1-cos(theta2))/2 theta3=2*pi*real(p3)/imag(p3),rad3=(1-cos(theta3))/2 theta4=2*pi*real(p4)/imag(p4),rad4=(1-cos(theta4))/2 theta5=2*pi*real(p5)/imag(p5),rad5=(1-cos(theta5))/2 v5=0.25+rad5*(cos(theta5)+flip(sin(theta5))) v1=0.25+rad1*(cos(theta1)+flip(sin(theta1))) v2=0.25+rad2*(cos(theta2)+flip(sin(theta2))) v3=0.25+rad3*(cos(theta3)+flip(sin(theta3))) v4=0.25+rad4*(cos(theta4)+flip(sin(theta4))) r12=v2-v1,r13=v3-v1 r23=v3-v2,r24=v4-v2 r34=v4-v3,r35=v5-v3 r41=v1-v4,r45=v5-v4 r51=v1-v5,r52=v2-v5 bailout=4 ENDIF pti=imag(scrnpix)*cols+real(scrnpix) disti=floor(pti/rays),rayi=pti-disti*rays z=0 IF(rayi==0) C=v1+(disti*2+1)/rctx2*r12 ELSEIF(rayi==1) C=v1+(disti*2+1)/rctx2*r13 ELSEIF(rayi==2) C=v2+(disti*2+1)/rctx2*r23 ELSEIF(rayi==3) C=v2+(disti*2+1)/rctx2*r24 ELSEIF(rayi==4) C=v3+(disti*2+1)/rctx2*r34 ELSEIF(rayi==5) C=v3+(disti*2+1)/rctx2*r35 ELSEIF(rayi==6) C=v4+(disti*2+1)/rctx2*r41 ELSEIF(rayi==7) C=v4+(disti*2+1)/rctx2*r45 ELSEIF(rayi==8) C=v5+(disti*2+1)/rctx2*r51 ELSE C=v5+(disti*2+1)/rctx2*r52 ENDIF : z=sqr(z)+C |z|<=bailout }
Hiram Berry wrote:
Doug Stewart <Dastew@sympatico.ca> wrote: To: "Fractint and General Fractals Discussion" <fractint@mailman.xmission.com>
Jonathan Osuch wrote: <snip>
Back in th 1980s I wrote a program that drew some very nice pictures similar to these ideas. you need: starting x and y ending x and y number of points in between number of iterations at each point. I also had the colour changing for each iteration at the point. If someone would add this to fractint I am sure that it would be a hit.
If you choose the line properly you get very stunning pictures.
Right you are, Doug. Take a look at the image generated from the included FRM and PAR. These simply draw a pentacle through the main cardioid of the M-set with corners at the 0,1/5,etc. bud tangencies, and then render the points using the passes=o. I didn't have any idea that a "knot" of such complexity could result from such a simple shape! Do you remember the settings or general algorithm you used in your program? I am very interested in these slices of the M-set orbit image object, and if you would share your experience with these I'm sure others would appreciate it as well.
---Hiram
Give me a day or two and I will get it out of my backup disks. Doug Stewart
Hiram Berry wrote:
Doug Stewart <Dastew@sympatico.ca> wrote:
<snip> Back in th 1980s I wrote a program that drew some very nice pictures similar to these ideas. you need: starting x and y ending x and y number of points in between number of iterations at each point. I also had the colour changing for each iteration at the point. If someone would add this to fractint I am sure that it would be a hit.
If you choose the line properly you get very stunning pictures.
Right you are, Doug. Take a look at the image generated from the included FRM and PAR. These simply draw a pentacle through the main cardioid of the M-set with corners at the 0,1/5,etc. bud tangencies, and then render the points using the passes=o. I didn't have any idea that a "knot" of such complexity could result from such a simple shape! Do you remember the settings or general algorithm you used in your program? I am very interested in these slices of the M-set orbit image object, and if you would share your experience with these I'm sure others would appreciate it as well.
---Hiram
I got my old pascal program running and produced a couple of pictures http://dougs.homeip.net/p1.bmp http://dougs.homeip.net/p2.bmp These are not the best but they do show what i was seeing back in the 80's. I think I only had 16 colors back then in the VGA mode I was using. I am running XT with a Virtual PC dos partition. I have fractint running in this virtual dos 6.22 and I was able to run my old program, that accessed the video card directly.
Doug Stewart <Dastew@sympatico.ca> wrote:
Hiram Berry wrote:
Doug Stewart <Dastew@sympatico.ca> wrote:
<snip> Back in th 1980s I wrote a program that drew some very nice pictures similar to these ideas. you need: starting x and y ending x and y number of points in between number of iterations at each point. I got my old pascal program running and produced a couple of pictures http://dougs.homeip.net/p1.bmp http://dougs.homeip.net/p2.bmp These are not the best but they do show what i was seeing back in the 80's.
Thanks, Doug. The way the curves behave looks remarkably familiar to the behavior in some of the Mandelbrot orbital images-- what are the iterating functions?
I think I only had 16 colors back then in the VGA mode I was using. I am running XT with a Virtual PC dos partition. I have fractint running in this virtual dos 6.22 and I was able to run my old program, that accessed the video card directly.
It certainly shows that Moore's Law doesn't apply to ideas. Those images are as thought provoking now as they were then. Has your experience with using "Virtual PC" been good? Ie. I assume you were able to use the old compiler under it? ---Hiram
Jonathan Osuch <osuchj@avalon.net> wrote:
On Thursday 18 November 2004 12:58 am, Hiram Berry wrote:
[snipped]
When we zoom in, though, the domain pixels (the parameter values used for the orbits) will be accordingly changed, right? What I want to do is to possibly get the domain values from a different area than what the screen is showing for the display range, without having to change parameters on the z-screen if a zoom is done.
Ah, the light comes on! Would using the default coordinates for each fractal type be acceptable? Yes; for user written FRMs further translation can be done by hand, though my experience of the last few days trying to implement that by translating from the scrnpix coordinates is that it is tedious. The real need is for Fractint built-in types where this is not even possible for the user. If the domain remained constant at the default coords, the image should at least be invariant with zooming, though a whole lot of points are going to be offscreen. Alternatively, I am planning to add a <cntl-p> screen with passes options on it and default coordinates could be on it. Possibly just an X and Y value, and then show -X to +X and -Y to +Y on the screen.
From a user's standpoint I like that a little better; it gives a lot of leeway for choosing the domain for the orbit image.
The first option is preferable from an impementation standpoint since it wouldn't involve adding additional parameters to PARs and GIFs. I've already done it in my version, and it does prevent rotating the image, as was done with the Demonic_Moose image.
Well that's certainly understandable.
Yes, but that mapping is fixed to the screen rectangle. I'm suggesting the possibility, of say mapping scrnpix to the inside of the cardioid r=(1-cos(theta))/2 for example if we only want to see the orbits from the points originating on the period=1 cardioid of the M-set.
So, instead of plotting: for (row=0, row<ydots, row++) for (col=0, col<xdots, col++)
we could plot: for (theta=0, theta<360, theta++)
Or something similar.
Yes, for the circle its trivial, and not much harder for the cardioid, BUT what's hard is distributing the points with even density within those areas without incurring a whole lot of computational overhead, at least that's how it looks from where I'm sitting. I had wanted to see what the orbit image of the subset of the Mandelbrot set lying only on the rim of the main cardioid looked like by this point in time, but I haven't been able to distribute the points on the curve evenly yet. Still, for purposes of development, don't forget that many subobjects of the M-set are more or less circular, so having an option to choose a disk shaped area is reasonable. ---Hiram
On Thu, 18 Nov 2004, Jonathan Osuch wrote:
On Thursday 18 November 2004 12:58 am, Hiram Berry wrote: (...)
Yes, but that mapping is fixed to the screen rectangle. I'm suggesting the possibility, of say mapping scrnpix to the inside of the cardioid r=(1-cos(theta))/2 for example if we only want to see the orbits from the points originating on the period=1 cardioid of the M-set.
I don't know how to convert that to cartesian coordinates in this case. Your map for the domain is stated in a way that converts easily to polar coordinates, and I know that there are conversions between them. Once you have this stated in terms of what x and y equal, isn't it just a matter of initializing zed and see to your domain? The equations I submit to the list typically have zed and see assigned to variable functions for a purpose similar to yours.
<brewhaha@freenet.edmonton.ab.ca> wrote:
On Thu, 18 Nov 2004, Jonathan Osuch wrote:
On Thursday 18 November 2004 12:58 am, Hiram Berry wrote: (...)
Yes, but that mapping is fixed to the screen rectangle. I'm suggesting the possibility, of say mapping scrnpix to the inside of the cardioid r=(1-cos(theta))/2 for example if we only want to see the orbits from the points originating on the period=1 cardioid of the M-set.
I don't know how to convert that to cartesian coordinates in this case. Your map for the domain is stated in a way that converts easily to polar coordinates, and I know that there are conversions between them.
Well yeah, that's the equation of the main cardioid bud of the M-set, defined in polar coordinates with the interesting cusp point (0.25,0) as the center. It isn't as nice expressed in cartesian coordinates. I guess the conversion could be done with the usual (x,y) = (r*cos(theta),r*sin(theta)), equivalently (r,theta)=(sqrt(x^2+y^2),atan2(y/x)), with computational fixup nicities added to avoid asymptotes. All of the buds of the M-set including the ones on the midgets are either cardioids or circles or stretched distortions of same, so I thought arbitrary circles and cardioids might be a good way to define the domain areas, for purposes of exploration.
Once you have this stated in terms of what x and y equal, isn't it just a matter of initializing zed and see to your domain?
Yes, and that's what I've done with the .frms to explore this: map the screen rectangle onto the desired "zed and see" before running the iteration. The problem is that has to be tediously manually added with each fractal type, and it can't be done with fractint builtin fractals. Currently the screen rectangle supplies all the starting points, raw unmapped, if you render a builtin type. I just thought it would be helpful if it were possible to specify the domain area in some way directly with passes=o. The reason for wanting this is to easily explore the form of the orbit objects, which generally are different from their parent objects. If the screen is centered around a particular feature, the orbit points may not lie on the screen rectangle. In particular, I've found that orbit images of a single minibrot only generate a multiplicity of objects in the orbit image-- their count appears always equal to the periodicity of the minibrot's main cardioid. Often these are far away from the midget itself, and may be much larger. There is some fundamental meaning in this which I don't yet grasp, but I'd like to look at other Mandeloid types to see if the relationship holds. I think it might be a consequence of the orbits themselves constrained to be in some sense "parallel", as is claimed in the fractint documentation.
The equations I submit to the list typically have zed and see assigned to variable functions for a purpose similar to yours.
Yes, I've noticed that, but wouldn't it be easier to be able to include that standard kind of transformation in the .par, or from a screen? The orbital fractals are especially handicapped in this because we ordinarily use the screen coords to specify the range of our view, but with them were using those coords to specify both the domain and range, so there are inherent limitations on where we can look without explicitly doing the mathematical gymnastics you are obviously familiar with. As an example, Jim recently posted about using the quat M-set. That one doesn't show anything with passes=o as far as I could determine, apparently because the orbits are plotted from the z-values each iteration, and a quaternion has to be expressed by 4 values so there's no way it could possibly plot the right thing out of the box. And the quat formula is builtin so there's no way to do a workaround to make the orbits show up. ---Hiram
Hiram,
Jim recently posted about using the quat M-set. That one doesn't show anything with passes=o as far as I could determine, apparently because the orbits are plotted from the z-values each iteration, and a quaternion has to be expressed by 4 values so there's no way it could possibly plot the right thing out of the box. And the quat formula is builtin so there's no way to do a workaround to make the orbits show up.
The quaternion types and the hypercomplex types don't work with the passes=o option because they don't use the 'new' variable. I had caught the lyapunov type but missed these. Unless I change my mind, they will have the passes=o option disabled for them in my next patch. Jonathan
On Wed, 1 Dec 2004 18:19:55 -0600, Jonathan Osuch <osuchj@avalon.net> wrote: "I had caught the lyapunov type..." I have tried the lyapunov type with passes=o, but it automatically reverts to passes=1 every time. What's the secret? Tony Hanmer
Tony,
I have tried the lyapunov type with passes=o, but it automatically reverts to passes=1 every time. What's the secret?
The lyapunov type won't work with passes=o because it doesn't use the correct variable. For most orbit type fractals each iteration determines a location on the complex plane. This location is stored in the complex variable 'new' and becomes in some predetermined fashion an input into the next iteration. Since the lyapunov type doesn't use the 'new' variable, I have added code to make the passes option revert to '1' if passes=o and fractype=lyapunov are selected at the same time. I will do something similar with the hypercomplex and quaternion types for the same reason. As you can see by trying them with the passes=o option, they don't generate an image. Might it be possible to slip the complex variable 'new' in such that passes=o generates an image with these fractal types? Yes, but that will take some study of the code. Jonathan
On Thursday 02 December 2004 10:57 am, Jonathan Osuch wrote:
Might it be possible to slip the complex variable 'new' in such that passes=o generates an image with these fractal types? Yes, but that will take some study of the code.
The inside and outside options are/were broken with the hypercomplex and quaternion types for the same reason, so I did add the 'new' variable for them. The lyapunov is a different beast using its own engine, and for now, it won't get fixed. Jonathan
On Wed, 17 Nov 2004, Hiram Berry wrote:
I understand that the periodicity=0 option is supposed to not plot orbits that go off the screen or bailout.
No. Going off the screen has nothing to do with it. And you CAN'T plot points that go off the screen (consider the virtual screen to be real, because it does take space in your video RAM). If you don't want to plot points that exceed the bailout value, then set outside to "numb". The periodicity checking is an approximation of the inner set. If the orbit cycles or becomes periodic, then enabling periodicity checking (and I disable it by default) will detect this and count the pixel as inside before the iterations maximum has been reached. It is more effective in saving time at high iteration counts. Methods { ; A look at the internals of tesseral, border tracing, ; and diffusion at the inversion of where x=log(2)/2. ; (A slight revision of my previous posting, this ; zooms in slightly to make border-tracing work). reset=2003 type=mandel passes=b center-mag=-0.533722/6.66134e-016/1.00621/1.5686/-90/3.885780586188047\ 89e-016 params=0/0 float=y maxiter=255 fillcolor=2 inside=255 invert=0.47/-0.333333333333333/0 periodicity=-2 colors=0zzzzz00zz0zz0Wz00zV0zz0<3>0z00zV0zz<3>00zV0zz0z<3>z00<3>ze0zo0\ zz0Wz00z0<3>0ze0zo0zz<3>00zV0zz0z<3>z00<3>ze0zo0zz0<3>Lz0Bz00z00zV0zz<\ 3>0Lz0Bz00z<3>z0zz0Wz00<3>ze0zo0zz0<3>0z0<3>0ze0zo0zz<3>0Wz0Oz0Gz08z00\ z<3>z0zz0Wz00<3>zz0Wz00z0<3>0zz<7>0Rz0Nz0Iz<3>00z<3>z0z<3>z0Lz0Bz00zV0\ zz0<3>az0Wz0Qz0<3>0z00zV0zz<3>0Lz0Bz00z<3>e0zo0zz0z<3>z00<3>ze0zo0zz0<\ 3>Lz0Bz00z00zV0zz<3>0az0Wz0Qz<3>00zV0zz0z<3>z00zV0zz0<5>Wz0Rz0Lz0<3>0z\ 0<5>0zV0z_0ze<3>0zz<3>00zV0zz0z<3>z00<3>ze0zo0zz0Wz00z0<3>0zP0zV0z`<3>\ 0zz<3>000 } The above fractal was meant to be rendered with different methods, but I'll explain what I see in this. The yellow and white lines both contrast with blue. You'll see where x=-.16 and y=.6 that blue and yellow dominate. With passes=g, this area will be filled with yellow. With passes=d, you'll get the same thing. Only tesseral identifies this as disputed territory. What about border-tracing? It colours the disputed territory, and ONLY the disputed territory. _______ Shaw's Principle: Build a system that even a fool can use, and only a fool will want to use it.
SherLock<brewhaha@freenet.edmonton.ab.ca> commented earlier:
On Wed, 17 Nov 2004, Hiram Berry wrote:
I understand that the periodicity=0 option is supposed to not plot orbits that go off the screen or bailout.
No. Going off the screen has nothing to do with it. And you CAN'T plot points that go off the screen (consider the virtual screen to be real, because it does take space in your video RAM).
While I can imagine a facility where you _could_ plot offscreen points to a virtual screen buffer(linked list of points or some such), which in a trivial sense the disk modes do, that isn't exactly what I was referring to. To clarify, note that I said "orbits", not "points". "orbit" = set of points, and going off the screen does apparently have something to do with the rendering with {passes=o,periodicity={on||off}} at least if the fractint.doc file is to be believed; to quote from the section on passes=o: A non-zero value of the "periodicity=" option causes Orbits to not plot orbits that have reached the bailout conditions or where an orbit goes off the visible area of the image. A zero value of periodicity will plot all orbits except as modified by orbitdelay and orbitinterval. [snip good explanation of normal operation of periodicity checking}
It is more effective in saving time at high iteration counts. Yes, but we're concerned here only with its behavior with the "passes=o" option, which seems to be a little different than when other drawing methods are used. The problem is that if periodicity checking is turned on, and it behaves as quoted above, some inside orbits may contain points that are offscreen, and if I interpret the quote correctly it means none of the points in that particular orbit will be plotted. Union a set of orbits which behave similarly, and entire subobjects of the orbit set (eg. orbit-space images of the buds of the M-set) may disappear from the image. To me, the orbit image of the M-set is an interesting object in its own right, visually different from the M-set and worthy of exploration without parts of it vanishing, so it seems that I have to use the periodicity=0 setting to get an accurate rendering.
Also, having benchmarked the periodicity options with passes=o, I didn't find much difference in the render times between on and off, so it appears that the actual periodicity checking mechanism is turned off when invoked from the passes=o mode. ---Hiram
Hoh, man. I am not in the mood to discuss an operating system that insists on being unstable after I hit the off switch, so I hope it's a good sign that there is one binary and one source AND I would ask that you name the binary to fit 8.3 DOS conventions. I think that would be frain203.zip, but if memory serves, that particular zipfile was missing some executables that came with frain200.
participants (5)
-
brewhaha＠freenet.edmonton.ab.ca -
doug Stewart -
Hiram Berry -
Jonathan Osuch -
Tony Hanmer