In superMB the number of skipped iterations is slightly reduced when using higher resolutions. This is because the tests depend on the pixel size. There is IMHO no reason to make the SA number of terms depend on the resolution. the only criteria are the speed of computation and error. Both are related as the complexity and per iteration errors magnitude are O(n?) where n is the number of terms. The optimal number of terms is about 32 - 64 in most cases.

Thanks for those links, I will have fun digging into the math, I've found out for holomorphic functions there are more accurate truncation error estimates, involving contour integrals. May be a dead end, I suspect knighty already looked into that.

Truncation error in SA is one thing, rounding errors in the SA coefficients another (never considered AFAIK ), maybe if we sum them we get the right error in the perturbed orbit when we start the actual iteration (after the SA shortcut), and we get a glitch condition without need to set some arbitrary tolerance, by simply using the current "gerrit" formula (which I'd rather call knightyV2 as all I did is slightly improve on his groundbreaking idea) with the right \( \epsilon \) which could turn out to be as simple as \( \epsilon ={\rm rounding\ error}/{errGlitch} \). If (big if) that works we then have a sound theoretical way to get it right, and then it's time to cut corners to get something close that is practical and more or less correct.

I never considered using truncation error estimation using contour integrals, slightly complicated for me

. It would be cool to see what it gives.

The effects of truncation error are mainly smooth deformations which are usually not very objectionable especially when restricted to one pixel radius or less. The rounding errors are more problematic. They give noise and/or blocky glitches. The more terms and iterations the more likely it will happen. There are some

renderings by Claude showing that effect in this thread. There are two kinds of rounding/cancellation errors in SA : in the computation of the coefficients and in the evaluation of The SA for per pixel processing. I mean that even if there are no rounding errors in the SA coefficients, it is possible to have them in the evaluation of the SA polynomial. It is of course possible to estimate those rounding/cancellation errors in the same way (Ok! more complicated) as for glitch detection. An in depth analysis of all this stuff would be a good subject for a numerical math graduate student. ;o)

Am I correct in thinking that smb can now run without SA at all by setting skip=0?

I tried the previous glitchy example with skip=0: now Kn KnPdb Gerrit and GerritB all render glitch free with the theoretical value tol=1!

Super hyper cool!

When setting skip=0 smb will report 2 iterations. The first iteration is because we actually begin at iteration 1 (z is set equal to c at initialisation). The second is because the step function of series_approximation class is called at least once.

Using smb on many locations I've found that GerritB (summing all errors each step) with the theoretical tolerance \( \Delta w/\Delta w' < h \) with \( h \) pixel radius, resulting from assuming \( |\Delta w|=|w|\epsilon \) with \( \epsilon \) machine precision "always" works, provided m, the number of iteration to skip, is sufficiently (unrealistically for practical purposed) small.

When using a small number of skipped iterations, most of coefficients remain very small until a period is attained. I guess that one could use a skip=smallest_period and a glitch detection tolerance of 1 without problem. That's just a guess... + tried it in the "amp4glitch" location: the first period is at 257 iterations. setting skip=257 gives correct render with tol.=1. If skip=258, tol. have to be set to 0.01 to get correct result.

BTW: Now superMB finds automatically the maximal number of skipping possible for the "light years away" location. (313084 with 64 coefficients)

Here is a picture of Dinkydau's "triangle tiling" location. it took about 25 min at 2560x1440 resolution to render (downsampled to 640x360).