Continuous, smooth version of Z*Z + C (the Mandelbrot orbit rule)

[Levi]

Hi all,

I've been working on an algorithm to create a continuous, smooth version of the Mandelbrot rule - basically so each point has a smooth orbit for computing partial iterations.

I've come up with an algorithm that makes this possible, given any continuous (non-smooth) function to compute the partial iterations.
The typical continuous function is:

Z(i) = M( floor(i) ) ^ ( 1 + i%1 )  +  z0*( i%1 )

Where M(i) is the regular integer Mandelbrot rule, 'floor(i)' is i rounded down to the nearest integer, and 'i%1' is the decimal part of i.

My algorithm is this:

Smooth(i) = {
  
  if ( i%1 < 0.5 )  
      ( M( floor(i) ) ^ ( 1 + i%1 )  +  z0*( i%1 ) ) * ( sin( (i%1)*pi ) + 1 )*0.5
      + ( M( floor(i) - 1 ) ^ ( 1 + i%1 + 1 )  +  z0*( i%1 + 1 ) ) * (1 - ( sin( (i%1)*pi ) + 1 )*0.5)
  else
      ( M( floor(i) ) ^ ( 1 + i%1 )  +  z0*( i%1 ) ) * ( sin( (i%1)*pi ) + 1 )*0.5
      + ( M( floor(i) + 1 ) ^ ( 1 + i%1 - 1 )  +  z0*( i%1 - 1 ) ) * (1 - ( sin( (i%1)*pi ) + 1 )*0.5)

}

Which essentially blends the current continuous iteration function with either the previous or following continuous iteration function, depending on how far along it is in the iteration.  I use sine to weight the averaging, because I found that linear weights created jagged edges.

The result is a smooth orbit that still follows the general path of the original continuous orbit.

Non-smoothed:


Smoothed:



More pictures can be found with the program/source code.

My program also has an example of this algorithm applied to an exponential-continuous Mandelbrot orbit as an alternative to the one posted above.
Feel free to use either of these algorithms for your programs, but make sure to give credit if you're distributing!

Executable, source code, etc. can be found at:  
https://www.dropbox.com/sh/h72wf9t5gi5yt5a/vHx7x7njLE


Thoughts? Ideas? Improvements?

[makc]

how is it different from, say, connecting the dots with cubic spline?

also, where are the images? I assume this alters the border of the set.

[Levi]

If you connected the iterations with a spline, the partial iterations would have no mathematical significance - it would simply be some path that connects the dots together. However, there are various definitions for what path the partial iterations "should" follow, such as the Z(i) = M( floor(i) ) ^ ( 1 + i%1 )  +  z0*( i%1 ) definition. The problem with these paths is that they are smooth only between iterations--they have a cusp at the integer positions along the orbit.  This algorithm removes the cusp while still staying mostly true to the original continuous orbit.

Sorry the images weren't visible to others before, I think I fixed it.

The images are intended to illustrate the non-smoothed and smoothed continuous orbits, respectively - the Mandelbrot images in the background serve simply as a map, and were not computed with partial iterations. Partial iterations should not be used to calculate escape time, because this may alter the shape of the rendered set. Rather, they are useful in several situations such as building attractor maps, or when 'stirring' the Mandelbrot set as seen here: <a href="http://www.youtube.com/v/dQ7kj2jCUJs&rel=1&fs=1&hd=1" target="_blank">http://www.youtube.com/v/dQ7kj2jCUJs&rel=1&fs=1&hd=1</a>  (video and 'stirring' concept are credit of Tim Hutton)

The video is a good example of where using a smoothed partial iteration might have been useful--at the end of each iteration, you clearly see the rotation switch direction. My algorithm would result in a continuous, smooth, swirling effect while still creating the same image in the long run.

[makc]

Ok, let me ask it in other way:

If you connected the iterations with a spline, the partial iterations would have no mathematical significance - it would simply be some path that connects the dots together. However, there are various definitions for what path the partial iterations "should" follow, such as the Z(i) = M( floor(i) ) ^ ( 1 + i%1 )  +  z0*( i%1 ) definition.

What exactly is "mathematical significance" of Z(i) = M( floor(i) ) ^ ( 1 + i%1 )  +  z0*( i%1 ) definition that spline does not have?

[kram1032]

First you say, you "chose" cosine interpolation because you "discovered" that linear interpolation causes jagged edges, heavily implying that *any* interpolation technique should be fine, and then you say, that spline techniques are somehow "not mathematically significant".

This is nice and all but to be clear: All of this is mathematically arbitrary. It would only have significance on a research-mathematical level if you somehow obtained a natural way of finding smooth paths. That technique would be somehow directly coming out of the formula, or it would have other nice properties.

[Levi]

@makc:
The Z(i) = M( floor(i) ) ^ ( 1 + i%1 )  +  z0*( i%1 )  is one of the more intuitive definitions that I have seen used from place to place to describe partial iterations. There is, by no means, a true definition for partial iterations, and there probably will never be unless a closed-form version of z->z*z+c is discovered. But this equation is one of the ones that make the most sense. There are others though, and my algorithm can be used to smooth any of them. (In my source code I actually apply the algorithm to another definition as well).

@kram:
Sorry if there was any confusion. My algorithm is more or less a method of smoothing the edges between piecewise definitions of partial iterations.
You could use it on a spline such as the Catmull-Rom, but of course the spline is already smooth.
The point is to use it to smooth other intuitive, non-smooth definitions of partial iterations, several of which have been proposed. I will try to find some links of examples.
Also, the jagged edges created by linear weighting (not quite linear interpolation, but similar) were only aesthetic - I believe the curves were still twice-differentiable, but they turned too fast for the eye to see, making them look like corners.
But yes, as I say above in my response to makc, this is not a "true" definition of partial iterations, it is simply a makeshift algorithm which I believe some people may find useful.



EDIT:
Here are some useful links to compare and contrast interpolation techniques against the Z(i) = M( floor(i) ) ^ ( 1 + i%1 )  +  z0*( i%1 ) technique, which is an intuitive extension of the regular Mandelbrot rule. It looks messy in the format that I've presented it but perhaps these articles will provide more insight about how it is derived from the rotation-translation effect of performing z->z*z+c.

Original thread about stirring by Tim Hutton : http://www.fractalforums.com/mandelbrot-and-julia-set/animating-fractional-iterations-'stirring'/
Article showing the rotation effect of complex multiplication : http://www.clarku.edu/~djoyce/complex/powers.html
And a google+ post also by Tim Hutton, showing several videos : https://plus.google.com/117663015413546257905/posts/WzjeMQx41LJ

If you scroll to the bottom of the google+ page, it shows a video of stirring done with linear interpolation. As you can see, the rotation-translation nature of the Mandelbrot rule is not visible as it is in the other videos which use the 'z=z^(t+1)+ct' rule, which is equivalent to 'Z(i) = M( floor(i) ) ^ ( 1 + i%1 )  +  z0*( i%1 )' but does not explicitly state the nature of the t variable.

[eiffie]

Thanks Levi I find this interesting and I have played around with these ideas a bit.  I agree with the others any kind of smoothing is going to be arbitrary but still useful.  I once tried just making the formula continuous by seperating the rotation, scaling and offset pieces and interpolating each. (It does not result in a smooth path.)

[Levi]

Hey Eiffie I see you posted while I was editing my previous post thanks for the response! A similar orbit is visible in my program (although it's invisible by default. You can turn it on by pressing alt+2.)  It involves rotating first, then translating. It doesn't have any interpolation though, I just included it for reference.

[kram1032]

Isn't the sine or cosine interpolation itself already smooth?
Or how did did you use the weights you mentioned?

[Levi]

I'm unsure if sine/cosine can be used to create smooth interpolation, but that's not how I'm using it. To clarify what I mean by weights, imagine that you have two functions g(x) and h(x) which intersect at x=b.  These functions are already interpolations of single iterations, but they have different derivatives at x=b. You want to create a function f(x) that is equivalent to g(x) for x<<b, and equivalent to h(x) for x>>b. At x=b, you want f(x)=g(x)=h(x).  However, for x near b (but not equivalent to b) you want f(x) to transition smoothly between the two functions.  So the way to do this is to take a weighted average of the two functions, where the weight varies with the distance between x and b. I.e.,

   f(x) = g(x)*w(x) + h(x)*(1 - w(x))

where w(x) is some function that returns a number between 0 and 1. I simply found that using a modified sine wave as my w(x) when x is near b resulted in a smoother transition than using linear functions. When x is not near b, you would want w(x) to return either a 0 or a 1 (1 when x is less than b, 0 when x is greater).

It's a little bit different for the Mandelbrot because, instead of having just two functions, you have infinitely many (one for every iteration). The key is to use this weighting system on only two functions at a time. I.e., if you are trying to compute the interval (1.5 < i < 2.5) you would be weighting the equations that correspond to iterations 1 and 2. You would want to weight them in such a way that, when i=1.5 you are just using the iteration1 equation, and when i=2.5 you are just using the iteration2 equation. At i=2, you would weight them evenly (although technically the two equations are already equivalent at i=2 ). Then, after i=2.5, you begin weighting iteration2 with iteration3.

Hope that clears everything up!

[matsoljare]

I'm thinking this could be a good candidate for the kind of rendering described here....
http://www.fractalforums.com/new-theories-and-research/supermandelbrot-and-superjulia-imaging

[Levi]

Hi matsoljare,

You're welcome to use my formulas if you like!! However, I'm not really sure I understand how partial iterations relate to the fractals in that thread. To my understanding, those images are essentially maps relating the areas of various Julia sets? In any case, it creates some very nice images

[kram1032]

Ok so what you're doing is a Beziér interpolation but instead of using an uniform parametrization over line segments, you parametrize them via cosines. Interesting that that would actually change its shape. While the curve would start off being drawn in either direction slower than in the linear case, it should go just as slow away from f as it would be drawn torwards g, effectively giving the same image. This happens because of the symmetries of sines and cosines.
The one thing that it effectively causes is, that there is a stronger bias torwards the knots (the individual interpolation points) and thus more detail in that region, while the middle would be less detailed. This could be why the curves look smoother in the cosine case...

[Levi]

Ok I just read the wikipedia article on Bezier curves, but it doesn't seem to be the same thing. The Bezier curve is a curve which fits inside a set of points. The curves I'm generating connect multiple entire functions.
http://en.wikipedia.org/wiki/B%C3%A9zier_curve
If you look at the very first image in the wiki article, you see four consecutively ordered points and a Bezier curve that is generated using them. If you consider those four points to instead be a set of three line segments, ie {p0_p1, p1_p2, p2_p3}, then it is more similar to the problem that I am working on. However, the solution created by the Bezier curve is not the same as the solution that my algorithm would generate: most notably, it does not pass through p1 or p2. My curve would pass through them.  It would also touch each line segment at its exact midpoint.


EDIT:

Here's an image similar to the ones I posted before, but maybe this will make it more clear:



In yellow are four separate functions, each defining a partial iteration orbit (this is not my algorithm but any partial iteration orbit you choose). The blue curve is the curve that my algorithm creates when applied to the four yellow curves. Each yellow curve is intercepted by the blue curve three times: once at either end, and once halfway along its path. These correspond to the times that g(x)=h(x) and the time that w(x)=0 (or 1), respectively.

It should be noted that I do not show the entire lengths of the yellow curves, but only the segment that would be used to define a partial iteration. My algorithm, however, uses extensions of the curves in both directions for its calculations.