SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.

[Kalles Fraktaler]

mrflay, even if you did not have the time to make your code open-source, can you give us any pseudo-code or something please?

I am trying to investigate this, however it seems that I didn't get it quite right.
I am still only using the arbitrary precision library.

The function is Dn
= 2*X*D + D*D + CD, where CD is the offset from the pixel I am calculating using the ordinary Mandelbrot calculation (D0), X is the Mandelbrot variable, D is the delta and Dn is the next delta.
The ordinary Mandelbrot calculation, where C is the location:
xin = 2*(xr*xi) + ci;
xrn = xr*xr - xi*xi + cr;

Before this, the new Delta-values are calculated, and cd is the difference between the X and the Y values:
dnr+dni = 2*(xr+xi)*(dr+di) + (dr+Di)*(dr+di) + cdr + cdi =>
dnr+dni = 2*xr*dr + 2*xr*di + 2*xi*dr + 2*xi*di + dr*dr + 2*dr*di + di*di + cdr + cdi =>

This is the resulting code:
dnr = 2*xr*dr + 2*xi*di + dr*dr + di*di + cdr;
dni = 2*xr*di + 2*xi*dr + 2*dr*di + cdi;

So in each iteration, the above is calculated and added to the Y value, and then checked for the absolute value not exceeding 2:
yr=xr+dnr;
yi=xi+dni;
if(yr*yr+yi*yi > 4)
  break;

However I only get the same value on Y as on X. The terms dr*dr and di*di get very small compared to  2*xr*dr and 2*xi*di
Can you or anybody please help?

[mrflay]

This is the resulting code:
dnr = 2*xr*dr + 2*xi*di + dr*dr + di*di + cdr;
dni = 2*xr*di + 2*xi*dr + 2*dr*di + cdi;

Did you include the minus signs from the i*i?

Here's my code:

Code:

// update dx
temp = 2*(x*dx - xi*dxi);
tempi = 2*(x*dxi + xi*dx);

temp += delta;
tempi += deltai;

temp += (dx*dx - dxi*dxi);
tempi += 2*dx*dxi;

dx = temp;
dxi = tempi;

[Kalles Fraktaler]

Thanks a lot!!! ,
yes I forgot the minus sign 

[mrflay]

My first open source project:
http://sourceforge.net/projects/suprfractalthng/

[blob]

Hi, it would be nice if you could compile a standalone jar file for desktop use for those like myself who have no clue what to do to compile this code into a useable application.

Thanks.

[mrflay]

Hi, it would be nice if you could compile a standalone jar file for desktop use for those like myself who have no clue what to do to compile this code into a useable application.

I might make that a project for this weekend - I think it needs some GPL information put in the about box.

[Kalles Fraktaler]

I have now had some time to investigated this a little.
The following two fractals are zoomed to just a little more than e100.
Only the top left pixel is calculated with the standard Mandelbrot function with a arbitrary precision library.
The rest of the pixels (of the 100x100 images, which are here magnified 4 times) are calculated with the SFT method with the standard double variables (the result is almost identical if I use the arbitrary precision library with the SFT method).

The first fractal (random colors different for each iteration) is near the edge rel:-1 img:0 and give a really promising result, there is only a little glitch in the middle of the spines, where the iterations are vary the most:


The second fractal (gradient colors) is in the "sea horse valley" (or actually on the opposite side, which I don't know the name for) and don't give any good result at all.


Is SFT accurate only near rel:-1 img:0 or does your program give better results?
The glitches are clearly visible even if I calculate every 3rd pixel with the Mandelbrot function.
If you are able to zoom into more complex regions, what ratio of Mandelbrot and SFT pixels do you use in your program?

[cKleinhuis]

regarding that your name sound like hitting head on the keyboard, thank you for those tryouts, why not choose a pixel in the middle ?
and to be true, this method can not guess points deeper iterated than the original point i guess

[claude]

Wow, nice technique!  I reimplemented the maths in OpenCL to run it on GPU (or CPU if you have no GPU that supports double precision):

https://gitorious.org/maximus/fractal-bits/trees/master/mandelbrot-delta-cl
http://code.mathr.co.uk/fractal-bits/tree/HEAD:/mandelbrot-delta-cl

Example output (25mins render time at 8192x8192 then downscaled):

http://mathr.co.uk/misc/2013-05-23_opencl_mandelbrot_perturbation_de.png

Coordinates
-1.744462934349396211092633065532440162654657162058301205300011967233679112768696718643911450570050500237635116030934362e+00 +
-2.204215166614661298784067716126285236126642700430015281578297171107705673910697920586811821018057499939594440402773182e-02 i
@  4e-99 period 5308

There are some white blobs that shouldn't be there - it's not maximum iteration count being reached, but something else (inappropriate reference point for those pixels? over/underflow somewhere?  mystery...)

[Kalles Fraktaler]

regarding that your name sound like hitting head on the keyboard,

All the names I wanted on youtube was already used so eventually I just hitted the keyboard, I am using the same name here since most of my youtube movies are fractal zooms

thank you for those tryouts, why not choose a pixel in the middle ?
and to be true, this method can not guess points deeped iterated than the original point i guess

You may regard the images as 200x200 pixels with the Mandelbrot pixel in the middle
And yes, the reference Mandelbrot pixel continues to be calculated in my test until all the SFT pixels are set, so in my opinion it should not matter if the SFT pixels are much deeper. However, you have a good point here and my opinion is wrong - if I use the deepest pixel as reference the fractal gets really good even in complex regions:

So, in order to make a general Mandelbrot explorer - how can the deepest pixel in an image be chosen prior calculation?
Or maybe we can just live with the errors it gets when just choose the pixel in the middle?

Edit:
The fractal above is zoomed to e103. Time to render the left image with the Mandelbrot function (in one thread) is 9.6s.
Time to render the right image is amazingly 0.072 seconds!!! There is an improvement of 133 times!!! A e103 image rendered almost instantly!!!

[cKleinhuis]

awesome results!!! mr flay has earned our non existant fractal nobel prize i believe!

to the choosen point, i think you are going to render animations, one thing is that the actual reference
point does not need to be recalculated for every frame, it just needs to be recalculated when quality
gets too low ... so, this is one, second is that the reference point should be user adjustable, especially
for rendering animations from time to time the reference points should require a re adjustment

woot woot, e100000000000 animations are visible soon

[cKleinhuis]

Wow, nice technique!  I reimplemented the maths in OpenCL to run it on GPU (or CPU if you have no GPU that supports double precision):

https://gitorious.org/maximus/fractal-bits/trees/master/mandelbrot-delta-cl

Example output (25mins render time at 8192x8192 then downscaled):

http://mathr.co.uk/misc/2013-05-23_opencl_mandelbrot_perturbation_de.png

Coordinates
-1.744462934349396211092633065532440162654657162058301205300011967233679112768696718643911450570050500237635116030934362e+00 +
-2.204215166614661298784067716126285236126642700430015281578297171107705673910697920586811821018057499939594440402773182e-02 i
@  4e-99 period 5308

There are some white blobs that shouldn't be there - it's not maximum iteration count being reached, but something else (inappropriate reference point for those pixels? over/underflow somewhere?  mystery...)

statistics about calculation time ? so, this method works well with gpu ?

who is in for implementing a ultra deep mandelbrot realtime zoomer on gpu, this would be just awesome, this task is open for anyone right now and it would have massively deep and huge impact, it might become a reference example for nowadays graphics cards

[Kalles Fraktaler]

the actual reference point does not need to be recalculated for every frame

Yes, I agree, an animation should only needed the center point to be calculated once! Amazing possibilities opens, not only very deep zooms but also very zooms with very high iterations will be possible!

woot woot, e100000000000 animations are visible soon

However, in order to exceed e308, which is the limit of a double, it is necessary to scale the values from the arbitrary library to double and then back again...
Any suggestions anyone?

[cbuchner1]

So screensavers performing a GPU based HD realtime deep zoom into a set of previously chosen deep locations should be easy to implement.

Has anyone checked yet if float vs double precision makes a difference?

[Kalles Fraktaler]

Has anyone checked yet if float vs double precision makes a difference?

I did not work for me with float, seems the precision is too low.