Hal,
What a periodicity failure looks like and what to do about it would be nifty to put into the docs sometime...
I'll add it. Thanks for the suggestion.
If I understand this correctly, Fractint first calculated a pixel that was in the 'lake.' Because of this the periodicity algorithm with Jim Muth's setting of periodicity=10 was switched on. The algorithm goofed and incorrectly claimed that the next pixel was in the 'lake.'
The algorithm then kept on making the same error all across the horizontal line of pixels in part because it still 'thought' it was in the 'lake' when it was not. At some point the periodicity checking got it right at the same time that a pixel was not in the 'lake.' The periodicity checking was then turned off and the horizontal line of lake color stopped being produced.
Is this correct?
Yes, that is correct. Also, the periodicity checking gets reset at the beginning of each horizontal line.
Both periodicity=0 and periodicity=15 fix the artifact.
Turning periodicity off is the better solution, as long as you don't need the periodicity checking because you have a lot of pixels in the lake along with a high iteration count.
While searching on "periodicity=" in the docs I ran across: "The inside=atan option should only be used with periodicity=0." and: "Type lambdafn function=exp needs periodicity turned off to be accurate -- there may be other cases."
I wonder if Fractint enforces the first two restrictions?
No to both. Although it would be possible to force periodicity off in these two cases, it would be ugly. If you momentarily change to inside=atan, then move on to another inside= option, how would the periodicity get reset? I did just look at this for inside=atan with the default mandelbrot and I think it needs to be added. There is a vast difference in the appearance of the image. And, using periodicity=15 (increasing periodicity) isn't an acceptable solution in this case. I'll put a fix in my next patch, which should be out in the next week or two. Jonathan