Help about implementing the perturbation theory

[laser blaster]

You still need to iterate, but single precision is sufficient then

Hmm... well I've been re-reading the pdf, and it seems to indicate that you can skip iterating for at least some of the points.

Now we can apply equations (3), (4) and (5) iteratively to calculate the coefficients for equation (2). Equation (2) can then be used to calculate the value for the nth iteration for all the points around X0. The approximation should be good as long as the (symbol)3 term has a magnitude significantly smaller then the (symbol)2 term.

It seems like the coefficients for equation 2 only need to be calculated iteratively for one pixel. Then you can use equation 2 to estimate the position of all the pixels in the surrounding areas, but only when the symbol(3) term is significantly smaller than the (symbol)2 term.

Am I misunderstanding this?

[Gluecker]

You can "skip" the first x iterations, where x is the minimum iteration count for the image to render (minus some tolerance maybe).
alternatively, using the Mariani/Silver algorithm (as described here) could be a efficient way to find x for subsections of the image.

broadly speaking: 2) can be used to approximate delta for any iteration (n), but (n) obviously has to be less than the number of iterations where the point is actually escaping to get the correct image, so you need to guess a good (n).

[therror]

Hello! I am trying to implement perturbation theory. I have written a code similar to example by Kalles Fraktaler 08.11.2013.

Code:

dnr=d0r=spix[l].p-Pmin;
dni=d0i=spix[l].q-Qmin;
yp=yq=n=0;
while (yp*yp+yq*yq<4&&n<nmax)
{
  dtr=2*(xref[n].p*dnr-xref[n].q*dni)+dnr*dnr-dni*dni+d0r;
  dti=2*(xref[n].p*dni+xref[n].q*dnr+dnr*dni)+d0i;
  yp=xref[n].p+dnr;
  yq=xref[n++].q+dni;
  dnr=dtr;
  dni=dti;
}

Reference point is calculated as double, other as float.
Picture is almost the same as usual set. But speed decreases about 2 times... IMHO, perturbation theory is ineffective at such magnification (4.93E-8). Isn't it? If I'm wrong, why speed decreases?

[youhn]

I do not fully understand, but will try to help.

Do you really mean that the calculation of the same image (same location, same resolution) is actually FASTER without perturbation ?! In that case, I think you've made a mistake somewhere. But please give some more insight into what you do, so we might be able to explain.

Question to help:
What is the location? (can you provide a KFR file?)
What is the resolution?
How much time does calculation WITHOUT perturbation take?
How much time does calculation WITH perturbation take in Kalles Fraktaler?
How much time does calculation WITH perturbation take in your software?

[therror]

All conditions is the same. Number of iterations, location, zoom, resolution. The only difference - few lines for perturbation and float instead double. (I never use bignum arithmetic)
Location: 
 range=4.9304E-8;
  xcenter=-0.743643900055;
  ycenter=0.131825890901.
Resolution 1280х1024. At 320x 256 usual calculation faster too.
w/o perturbation 221 second.
with perturbation 380 second in my program.
To compare with other software - good idea

[3dickulus]

you can find a C++ port of SFT here and some chatter about it here
this was ported directly from the java source and knighty helped (a lot, tnx btw) with a few bugs, it uses ArPrec lib for the full precision part.
the deepest I went with this code was E-2346 ish

[quaz0r]

he only said hes using perturbation, not series approximation.  also hes staying within the limits of hardware floating point.  so of course the extra overhead and unnecessary screwing around of perturbation is going to be slower than regular iteration.  and even if hes also using series approximation, lots of low-magnification locations will not benefit much from it, and the overhead of all that could still be slower than regular iteration.

[cKleinhuis]

he only said hes using perturbation, not series approximation.  also hes staying within the limits of hardware floating point.  so of course the extra overhead and unnecessary screwing around of perturbation is going to be slower than regular iteration.  and even if hes also using series approximation, lots of low-magnification locations will not benefit much from it, and the overhead of all that could still be slower than regular iteration.

this is what is second as well, the pertubation kicks in at ridiculous depth it might appear that it improves double->float as well, use max double range and use float for the rest, the thing here is that modern cpus do not have any significant double precision calculation time differencies anymore regarding float/double !!!

[therror]

Thanks, dear friends! I understand that perturbation don't help me.. But I have implemented border tracing(with rectangular borders)! I made skipped points visible, it is not error. Speed is much more!