<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