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 }