END OF AN ERA, FRACTALFORUMS.COM IS CONTINUED ON FRACTALFORUMS.ORG

I've tried the per pixel test AAAaaannnddd... It works!  
Here, for each pixel we compute:
error(delta) = R*|delta|^m+1/(|SA'(delta)| * dt)
The error is given in 0.5 pixel units.

This is the location "Adventurous forest" at zoom factor 4E47 (in kalles units). I used m=8. The first picture shows the result with 7745 SA iterations. The second with 7746 SA iterations. The red shades encode the error in delta space pixel units. At the center, that is at the reference point, it is 0. The first full red color from the center means 0.5 pixel error then 1 then 1.5... as we go further.


link In case there is no picture shown.
Notice the red shades at the upper left and lower right corners... and around the red blobs.


link
Notice that:
   - the error jumps while we added only one iteration.
   - the error is maximal where there was a blob.
   - because the estimation of the truncation error is conservative. The fractal is not deformed too much (but it is).

Here is a little gif animation shoing what happens between 7100 and 8000 SA iteration. In the last picture of the sequence there are no red shades, not because the errors were not detected but because the estimation of the truncation error overflowed.

[urlhttps://goo.gl/photos/QkXCjVoBaMEYhocT9]link[/url]

Finally, sequence for the same location at 8E40 (kalles zoom factor) with SA iteration going from 5630 to 6470.


link

And finally the source code attached.

I couldn't go beyond 50 terms because of overflows in the computation of R. It occurs when R reaches 1e2466 . Then when computing the absolute value there is a squaring which causes the overflow. R*tmax^(m+1) is still very small though.

The first picture attached is with 7940 skipped iteration and the second with 7950. Both use 50 terms. The one with 7950 terms is extremely deformed at the edges. Maybe round off errors?

It a WIP, many things still have to be done. 

From the beginning, this test was meant for testing and debugging purposes. But it shows so far, that kalles fractaler's method, by checking at some points (mainly on the border), is good. It is even possible to take it further by using the proposed formula:

  error(delta) = R*|delta^(m+1)|/(|SA'(delta)| * dt), I did a mistake in the previous post

R*|delta^(m+1)| can be estimated as the the absolute value of the difference between test and SA computed points.
SA'(delta) being the derivative of the SA polynomial is easy to compute
For dt and by security  , just take a small fraction of the pixels' width... say 0.01 pixel_width
... Then just take the max.

It is not bullet proof though.


I doubt an annulus IA would be effective because of the addition... It is more or less a minkowski addition. But who knows! Thank you for the idea.
There is another way that involves subdivision. The advantage is that it may give the regions where the SA is safe. The disadvantage is that it is maybe costly.

Anyway, the test doesn't have to be done each iteration. At 10000 max possible skipped iterations we can do it each 100 iterations. If we stop at 9900 we won't loose a lot of speed. There must be a good compromise.

I forget each time to mention that the estimation of R is related to interval taylor forms. See for example link.

KF is comparing the result from SA with 8 pixels around the edge of the view.
From the begining the threashold was 1e-3.
However I found one location where this threashold was too high.
Even though I have only found location one so far, after playing with this for a couple of years, I changed the default threashold to 1e-5 (so that is mabye why I don't find them anymore)

This location is the location:

I know that more iterations can be skipped closer to the reference point than on the edge of a view.
So I had an idea of making more SA start values as you closer to the reference point you get.
However, this particular location contradicts my assumptions, since it reveals than less iterations can be skipped in an area inside the view.
So one would need to be able to go up and down in the number of skipp-able iterations as you go closer to the reference point...

Low tolerance and correct render with 702 skipped iterations (for the first reference) in 640x360 is 0.698 seconds.
High tolerance and incorrect render with 705 skipped iterations is 0.687 seconds, so it is about the same.

Can you provide an example, because with "Low tolerance" active I haven't encountered any locations with glitches due to SA...?

I spent quite some time with this "how much can I skip" problem and in the end actual testing turned out to be the safest and reasonably efficient way (testing = compare skipped and not skipped values at a number of pixels). Analysing the behaviour of the series itself did not work out in the end because as the terms go up (and we usually want them to go up a lot due to the reference period rule) the contributions are spread around more and more in waves and it was unclear when to stop safely looking at contributions. The abrupt changes from ok to corrupted occur around period boundaries. They depend on pixel location and the reference used. And here is some probably new insight: Relevant period boundaries are not just the multiples of the period of the current reference, it's also all the other periods a pixel location is affected by, e.g. the partials. As far as I could see the boundaries from good to bad are always at a sum of multiples of the partials of the pixel. As one flies by a local minibrot the periods there become relevant and possible skipping goes down (when using a deeper down minibrot as reference). As one zooms further the local minibrot becomes less relevant again and only what one inherits from it in the partials can be relevant further down. Embedded Julia sets can further complicate this by adding corruption due to rounding errors independent of overskipping.

Your description reminds me of my "Simply Awesome II" rework of my first deep Mandelbrot Zoom. Kalles Fractaller produced glitch frames precisely in two locations where the render path deviated from the centroid. I imagine the periodicity of the alternate render paths was very different from that of the central minibrot.

http://sta.sh/01aqqf7kg83r


http://sta.sh/017skb4ouloa

Ultimately I left the glitch frames in the video because I did not know how to fix them without potentially corrupting the iteration data. Here is the final result:
<a href="https://www.youtube.com/v/vnUjXAIIcq0&rel=1&fs=1&hd=1" target="_blank">https://www.youtube.com/v/vnUjXAIIcq0&rel=1&fs=1&hd=1</a>