Bigger Newton's fractals

[gamma]

Take a look this amazing work:
http://home.hccnet.nl/titia.1/fractal/white.html

[cKleinhuis]

yes, this is titia, an amazing fractal artistine, and a very long and appreciated member  of this forum,
in fact, i have used this image for the banner on this site above, and exactly this image is also contained
in our gallery , do not know if it actually competed in last years spring competition ...   

no, it was just an entry, look here:
http://www.fractalforums.com/gallery/?sa=view;id=127

... but the one you posted is somehow bigger ...

[HPDZ]

On the subject, has anyone tried rendering a Newton formula with the real and imaginary components of the power varying with the x and y-axis?

I finally got around to trying this today. I've posted five representative examples with various values for the starting location.

To be precise, this shows the result of iterating the Newton's method formula applied to z^p-1=0, which is z = z*(p-1+z^-p)/p, where p is varied across the image: p=x+iy. The standard type of exponential smoothing is applied both to the convergent and divergent cases (I don't check which points do what).

The branch cuts caused by the complex exponents have a sort of Picasso-like effect. It reminds me of how I feel in the morning sometimes when I haven't had enough coffee....

I obviously didn't spend a lot of time on the coloring; these are just meant to give a rough feel for what it looks like. The images have either 3x3 anti-aliasing or 5x5. The color mapping is done with the count histogram.

This shouldn't be too hard to write in UF; maybe I'll do this as an exercise in learning how to write UF formulas.

[cKleinhuis]

the first one sho0ws a nicve grid 3d structure

[gamma]

On the subject, has anyone tried rendering a Newton formula with the real and imaginary components of the power varying with the x and y-axis?

I finally got around to trying this today. I've posted five representative examples with various values for the starting location.

To be precise, this shows the result of iterating the Newton's method formula applied to z^p-1=0, which is z = z*(p-1+z^-p)/p, where p is varied across the image: p=x+iy. The standard type of exponential smoothing is applied both to the convergent and divergent cases (I don't check which points do what).

Hi. It seems that changing the imaginary part often leads to rotation/twisting or better "spiraling" effect observable in 4th and 5th image. Curves/contours are not closed then. Try real power.

(phew "try real power"?)

[HPDZ]

"Try real power" ... can you elaborate/clarify?

The images vary the exponent over the complex number plane, so using only a real power would mean the image would just be a single line... Perhaps my initial explanation wasn't clear, or perhaps you mean to try something else?

[gamma]

"Try real power" ... can you elaborate/clarify?

The images vary the exponent over the complex number plane, so using only a real power would mean the image would just be a single line... Perhaps my initial explanation wasn't clear, or perhaps you mean to try something else?

Yes! Raising to power with imaginary number is causing a kind of twisting effect and we have these sharp lines interrupting the smooth, , round, continuous flow of contours. You probably know all that.Then, p would slide only across the X axis. 

[HPDZ]

Right. The sharp interruptions are due to what are called "branch cuts" in the logarithm function that's used to calculate the complex exponentiation.

But if I were to only scan along the real axis, wouldn't the image just be a single line? Or perhaps you have another way of scanning that I'm not understanding?

[gamma]

I would not know, I can't see from your specification. I tried some formula in Ultrafractal and added
p=p+1 in each iteration (loop section). The result is still very Newtonian looking.
(at Harvard they take it as proof :-)

[HPDZ]

I would not know, I can't see from your specification.

Well, what I did for the five images above is pretty straightforward: I iterated the Newton's method function corresponding to z^p-1=0 with some fixed initial guess z0, letting the power p equal the coordinates of the pixel in the image. In other words, p=x+iy, where x is the horizontal coordinate in the image and y is the vertical coordinate in the image. As the image point moves, x and y change, so p changes across the image. But p stays fixed for a given pixel on the image as the loop iterates.

I tried some formula in Ultrafractal and added p=p+1 in each iteration (loop section).

What you describe here is quite different: It looks like you're changing p at each iteration, presumably starting from p=3 at the beginning of each pixel's iteration sequence. Interesting idea. I'll have to try it. I suppose a general increment dp, not necessarily 1, could be used as well....

[HPDZ]

I posted some examples of what happens when you increment the exponent to the "Rate my Fractal" forum under the topic "Exponent increment".

http://www.fractalforums.com/images-showcase-(rate-my-fractal)/exponent-increment/

Does this look like what you got?

[gamma]

I would not know, I can't see from your specification.

Well, what I did for the five images above is pretty straightforward: I iterated the Newton's method function corresponding to z^p-1=0 with some fixed initial guess z0, letting the power p equal the coordinates of the pixel in the image. In other words, p=x+iy, where x is the horizontal coordinate in the image and y is the vertical coordinate in the image. As the image point moves, x and y change, so p changes across the image. But p stays fixed for a given pixel on the image as the loop iterates.

I tried some formula in Ultrafractal and added p=p+1 in each iteration (loop section).

What you describe here is quite different: It looks like you're changing p at each iteration, presumably starting from p=3 at the beginning of each pixel's iteration sequence. Interesting idea. I'll have to try it. I suppose a general increment dp, not necessarily 1, could be used as well....

I understand. In Ultrafractal that would be, mystuff.ufm

init:
 ; per pixel initialization
 complex zold
 complex z=#pixel ;test every point of plane as starting guess; use (1,0) for "mandelbrot" mode
loop:
 z=z-(z^#pixel-1)/(#pixel*z^(#pixel-1))
bailout:
 |z-zold|>0.0000001


BTW, In outside coloring choose file mt.ucl, Newton Basin for coloring according to roots.

[HPDZ]

Essentially, yes -- this is the case of the exponent varying with pixel location but staying constant as the iterations progress.

I generated the images from my own program, which is in C++, but I have also tried using UltraFractal to replicate it. This is my first attempt to use UF's equation editor. 

My loop equation is the mathematically equivalent, simplified version of what you wrote. This form eliminates the redundant exponentiation (these are very expensive with complex exponents). I also added a couple of parameters.

Code:

init:
     z=@zinit
     p=#pixel
loop:
     oldz=z
     z = z*(p-1+z^(-p))/p
bailout:
     |z-oldz|>@epsilon

[David Makin]

Essentially, yes -- this is the case of the exponent varying with pixel location but staying constant as the iterations progress.

I generated the images from my own program, which is in C++, but I have also tried using UltraFractal to replicate it. This is my first attempt to use UF's equation editor. 

My loop equation is the mathematically equivalent, simplified version of what you wrote. This form eliminates the redundant exponentiation (these are very expensive with complex exponents). I also added a couple of parameters.

Code:

init:
     z=@zinit
     p=#pixel
loop:
     oldz=z
     z = z*(p-1+z^(-p))/p
bailout:
     |z-oldz|>@epsilon

Note that unless you really need "p" to be a variable you should not assign #pixel to "p", you should use #pixel directly - tthe runtime version will be faster as it saves a level of indirection.

[HPDZ]

Note that unless you really need "p" to be a variable you should not assign #pixel to "p", you should use #pixel directly - tthe runtime version will be faster as it saves a level of indirection.

Thanks for the advice, David. I just did it that way for ease of reading. I had no idea it would affect the execution speed. I suppose assumptions from my experience in C/C++ do not necessarily translate to UF coding.