Welcome to Fractal Forums

Hi folks!

I've been rendering the Mandelbrot set with hardware arithmetic for some time, and I've familiarized myself with arbitrary-precision arithmetic enough that I can go beyond the double-precision type and still get by.

I went back and read the big SFT thread introducing perturbation and series approximation methods, and while I've made some progress with them so far, I've got some gaps in my understanding to fill:

1. How is the point used for a reference orbit selected? I understand it has to be as close to the maximum iteration count for the render as possible, but how can I select such a region (or regions) automatically?
2. Suppose I am computing the series A, B, C (and so on) for series approximation. What is the appropriate course of action for when the term and term are too close in magnitude?

I tried to read up on as much of the background material as possible, but these factors have got me stuck. I'm sure that everything else I'm missing will fall into place if I can get these more or less figured out.

Any help is greatly appreciated!

no responses...I guess nobody cares about this stuff any more?  :-\

the thing with this stuff is that its all kind of up to you to figure out what you think might be a good way to proceed  ^-^

1.  if you have any previous data to go on (from exploring or rendering a zoom animation), you could try keeping reference points from the previous frame that might still be good to use.  otherwise you just pick something to start the ball rolling (the most obvious blind choice is the center of the screen).  using pauldelbrot's glitch detection method you should be able to start with any reference point and refine things from there with further reference points as needed.

2. the appropriate course of action is to bail on series approximation once youve determined conditions like these have been exceeded.  if you go too far with the series approximation bad things will happen.

Maybe :

http://mathr.co.uk/blog/2014-03-31_perturbation_glitches.html

HTH ( claude is not active now )

claude, while a very smart guy, tends to relish in overcomplicating things as is common of certain smart folks  :angel1:
also i think that page was his contemplations on the matter previous to pauldelbrot's glitch detection method.  with the glitch detection method it really doesnt matter how you kick things off; it will work itself out in about as many steps regardless where you start.  if you have some information left over from a previous frame or something to use on the next, okay.  if not, whatever.

Thanks, folks. I'm alive!

It's been a while since I looked at this, but I found a fix for some of my problems. I don't remember if I ever found out what Pauldelbrot's glitch detection even was - I assumed it was to compare magnitudes of B and C terms, but I didn't find a good way to tell what the magnitude difference threshold should be.

Either way, I've open-sourced my code, which is up at https://github.com/axnjaxn/newman

I'll have to refamiliarize myself with my own code and remember what my remaining problems are...

the glitch detection happens at iteration time.  When you flag a point in this manner you then need to reiterate it with a different reference point.  he describes it here:
http://www.fractalforums.com/announcements-and-news/pertubation-theory-glitches-improvement/
one thing to note is that you have to check every single iteration or you won't catch them all.
as far as when to bail on the series approximation, the difference in magnitude here should be at least 1e-3 as well.

i tried building your libbyteimage but it bombs out for me

byteimage.cpp:46:26: error: invalid operands of types ‘double’ and ‘int’ to binary ‘operator>>’
   for (int i = MaxRGB >> 8; i & 1; i = i >> 1) nshifts++;

and such.  i guess it is probably due to my imagemagick being compiled with hdri and/or "quantum" level 16 or whatever imagemagick calls it?

I still care!
However both me and Botond, and also Claude I think, made the source of our programs publicly available. So the answer to these questions could easily be found in the code :)

I think we (and especially MM) have come as far as it gets with the plain 2nd power Mandelbrot formula. :)

But I have more suggestions for further research:

• More terms of Series Approximation of higher power Mandelbrot. knighty gave me 3 terms, but for 2nd Power we have obtained an algorithm to get an arbitrary number of terms. Such algorithm would be very nice to have for 3rd Power Mandelbrot, etc. Unfortunately my math skills are too limited, but this should be an easy task as long as you are able to derivate functions :)
• Series Approximation on abs variant of Mandelbrot, i.e. Burning Ship, Buffalo etc. I know it would be very advanced since it involves derivate of functions containing absolute values, and perturbation is already very advanced since it requires the abs operations to be handled with conditions
• More formulas... TheRedshiftRider gave me a load of Formulas combining different powers of the Mandelbrot formula. It might be just more of the same though...

that sounds like good stuff to do!  come on you guys hop to it   :D

Of course. I had a look at them and they are mostly the same and not very interesting as separate functions.

But there is one that would be interesing to implement:
z=(z^2+(c+(A+Bi)))^2+c
Where a and b are values chosen by the user. Although I dont know how this should be done because my lack of understanding of perturbation.

But this function is interesting because you could technically create a very large number of sets with very interesting areas to have a look at.

And one more thing I would like to see with perturbation/series approximation....

Julia!

I haven't made a study of perturbation or series approximation but it surprises me that Julia are difficult.
From my fractal Extreme burning ship plugin

Fractal Extreme manages the normal/julia mode by setting that values of JuliaI and JuliaR to the initial zi & zr values.
In Julia mode the JuliaI and JuliaR values are the Julia seed value.

I've noticed that the Julia versions of equations require extra precision much earlier than the standard especially when zooming into the 0r,0i origin.
Perhaps you need to allocate more precision?
I gather the point of perturbation is to avoid extended precision arithmetic and only do the high precision for the reference points.
So not having enough precision on the reference points in a Julia could seriously impact.

The attached picture shows a burning ship "untitled1" and the julia seeded version zoomed on the 0,0 origin "untitled 5".
Notice it needs 14 extra bits of precision, the julia needed 96bit calculations at only 30 zooms in.
Without the extra 14 bits the calculation would have been using floating point (64 bit? 80 bit?) and looked like the upper right corner of "untitled5".
The source burning ship was 102 zooms in using 128 bit calculations, it had crossed over from 96 bit at the 77 zoom depth.

I tried many options without success.
Seems there is something with the start values that makes the delta reference work only with Mandebrot...
http://www.fractalforums.com/index.php?topic=20168.0

Writing code to do the maths is probably easier than doing it by hand (less risk of mistakes like sign errors etc).  Before I ended up in hospital (back now, all better - hope to get fractal coding again soon) I was slowly working on some symbolic algebraic manipulation for automatic perturbation and series approximation code generation, some step-by-step output showing what it does internally is here: http://mathr.co.uk/tmp/symbolic-algebra.html

Since then I added differentiation to it too, and it generates C code parallelized using OpenMP, example in diagram form (each row is performed in parallel, each column is a real-valued variable using MPFR):  http://mathr.co.uk/mandelbrot/2015-05-21_parallel_4th_order_series_approximation_recurrence.png

My "Perturbator" code isn't yet published (it's a horrendous mess of Haskell that generates C code by concatenating strings..), but it worked well enough to generate this deep zoom test sequence: http://mathr.co.uk/mandelbrot/2015-06-12_perturbator_deep_zoom_stress_test/ (some ugly Moiré artifacts in the last couple of images from not colouring the DE black enough..).

welcome back (:-))