*Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.

[stardust4ever]

While I have a very advanced knowledge of complex math, infinite series and such are beyond me. This is why I flunked advanced Calculus! Carry on...

[knighty]

<Quoted Image Removed>

just curious, earlier it was written as |tmaxⁿ|, but according to this it seems to be |tmax|ⁿ.  should these be equivalent or should it be one or the other?

also,

<Quoted Image Removed>

this seems weird to me... for instance at m=3 and k=4, this seems to give 2(a₁a₃ + a₂a₂ + a₃a₁ + a₄a₀ + a₅a_-1 + a₆a_-2).  should that 2m instead be m ?

Oops! it is a copy past mistake! 
It should be :
I'll make the corrections to the previous post.

In the other hand we always have : |zⁿ| = |z|ⁿ

[Kalles Fraktaler]

added my own method of recursive glitch solving to the code, hopefully it is useful to see a simple implementation without multithreading optimisations getting in the way of understanding.

claude, I think your render is not correct.
You may have encountered the distortions near the edges as was showed by knighty.
I attached about the same location rendered in KF that is able to skip 3407 iterations with 126 terms.
Even with 1000 terms KF is not able to skip more than 3509 terms.
Sorry to spoil your progress...

[quaz0r]

indeed, i get the same render as kalles

skips 3544 iterations

this would certainly be the right number of iters to skip though if possible, as the min iter i get for this image is 3554.   

[Kalles Fraktaler]

indeed, i get the same render as kalles

this would certainly be the right number of iters to skip though if possible, as the min iter i get for this image is 3554.   

I think 3544 is too much near the edges.
I assume this is because of limited precision.
I guess it would be possible to skip all the 3554 only if the SA is calculated with the same precision as the reference of e42.

[quaz0r]

if possible

 

I assume this is because of limited precision. I guess it would be possible to skip all the 3554 only if the SA is calculated with the same precision as the reference of e42.

since the series approximates the delta instead of the whole value, i think the number of terms in the series is the only limiting factor?  with infinite terms i suppose you could get right up to within the min iter... though maybe as you get close the delta would indeed require more precision.  could that theoretically be a limitation on analyzing the coefficients only versus the old way of actually testing points?  i think the coefficient analysis should give a theoretically proper stopping point, though perhaps precision loss could potentially occur prior to this point?  ie this is what the automatic perturbation glitch detection does, detects catastrophic loss of precision, but i have never heard of anyone implementing such a check for the series approximation.  would it go on to be detected by the perturbation glitch detection?  or possibly get through undetected, which would result in went-too-far-with-SA style incorrectness.

another thought:  if SA precision loss was indeed an issue to be accounted for, and you added a check for it, perhaps this information could then also be used to provide feedback about how many series terms were actually useful up to the point where you had to bail due to precision loss?

[claude]

claude, I think your render is not correct.
...
Sorry to spoil your progress...

Well spotted!  Oh dear

EDIT:  I found the problem - my code was using a too-small tmax value (half the imaginary diameter of the image).  Increasing the tmax by a factor of 4 gives a correct render it seems!  This skips 3294 iterations with 16 terms, using knighty's first version of the R calculation (will see how the updated R iteration affects things next).

[Kalles Fraktaler]

 

since the series approximates the delta instead of the whole value, i think the number of terms in the series is the only limiting factor?  with infinite terms i suppose you could get right up to within the min iter... though maybe as you get close the delta would indeed require more precision.  could that theoretically be a limitation on analyzing the coefficients only versus the old way of actually testing points?  i think the coefficient analysis should give a theoretically proper stopping point, though perhaps precision loss could potentially occur prior to this point?  ie this is what the automatic perturbation glitch detection does, detects catastrophic loss of precision, but i have never heard of anyone implementing such a check for the series approximation.  would it go on to be detected by the perturbation glitch detection?  or possibly get through undetected, which would result in went-too-far-with-SA style incorrectness.

another thought:  if SA precision loss was indeed an issue to be accounted for, and you added a check for it, perhaps this information could then also be used to provide feedback about how many series terms were actually useful up to the point where you had to bail due to precision loss?

I tried with 10,000 terms, which took more than an hour to calculate and resulted in 3530 skipped iterations

[knighty]

The value of tmax is critical. It must be the distance from the reference to the farthest corner of the rendered area. If less, it will go too far in skipping.
In the other side the value of dt is much less critical.
In this particular location, with 16 terms, the test gives exactly the maximum iteration skip possible: 3298. With 32 terms, the max possible skip is 3380 while the test still gives 3298... strange! maybe it is the lower bound of the derivative that is preventing it to go further.

[Kalles Fraktaler]

Even though you are able to achieve a theoretically accurate way to find the highest amount of skippable iterations in a radius of the most farther point from the reference, which is a good improvement, can you be sure that you will capture totally entrapped areas within this radius where only a lower amount of skippable iterations is possible?

[hapf]

Even though you are able to achieve a theoretically accurate way to find the highest amount of skippable iterations in a radius of the most farther point from the reference, which is a good improvement, can you be sure that you will capture totally entrapped areas within this radius where only a lower amount of skippable iterations is possible?

I guess not because we are talking about fractals. 

[knighty]

Even though you are able to achieve a theoretically accurate way to find the highest amount of skippable iterations in a radius of the most farther point from the reference, which is a good improvement, can you be sure that you will capture totally entrapped areas within this radius where only a lower amount of skippable iterations is possible?

I'm not sure I understand your question. The whole thing is about having a guaranteed number of skipped iterations as to not have any deformation and that, over the whole rendered area. This guaranteed number will be always less or equal to the max skippable iteration number that is possible -without getting any deformation-.

That said, there is still some work to do in order to finish the test part.

[quaz0r]

can you be sure that you will capture totally entrapped areas within this radius where only a lower amount of skippable iterations is possible?

i believe this is exactly the point of interval arithmetic, to compute bounds that you can be sure will hold true over the given interval.

I'm not sure I understand your question.

i imagine those of us who are not math professors are likely unfamiliar with interval arithmetic.  also i think the experience thus far of testing against points and hoping for the best is tainting future optimism that there could actually be a better way  

[quaz0r]

im still not sure about this part..  when k=2m, for instance say m=3 and k=6, we get k-m=3 and =2.  ive never seen start higher and go lower.  was that your intention?

[stardust4ever]

i imagine those of us who are not math professors are likely unfamiliar with interval arithmetic.

This!