Hi,
calculating Mandelbrot sets in c++ (double precision) I have noticed strange artefacts when I zoom down quite deeply. I have no explanation for them. It seems as if the correctly rendered structures are being overlapped by large chunks with non-fractal borders.

I have attached a screenshot for better understanding.
It was calculated with these parameters:
x: -0.743747
y: 0.110228   
height: 2.56114e-10 
calculated with 5350  iterations

My code is:
int MandelbrotIterator::mandelbrotPlusTest(Complex &c, int maxIter)
{
    double r = c.vectorSquaredLength();
    double s = qSqrt(r-0.5 * c.x() + 0.0625);
    // test for head (circle) or body (cycloid)
    if ((16 * r * s > 5 * s - 4 * c.x() + 1) && ((c.x()+1)*(c.x()+1))+(c.iy()*c.iy())>0.0625) {
        Complex x = m_startX;
        int i = 0;
        do {
            i++;
            x.squareAndAdd(c);
        } while (x.vectorSquaredLength() <= 2 && i <= maxIter);
        if (i > maxIter) {
            i = -1;
        }
        return i;
    }
    return -1;
}

I would expect to see the beautiful structures from the bottom left corner to cover the whole area. The big flat one-color sections are clearly wrong - but I don't get, how!

Any ideas / similar experiences?

Linkback: https://fractalforums.org/programming/11/uni-colored-artefacts-in-deeper-zoom-levels/3238/

x.vectorSquaredLength() <= 2should be 4 (minimum) not 2

It was calculated with these parameters:
x: -0.743747
y: 0.110228   
height: 2.56114e-10 
calculated with 5350  iterations

I tried to reproduce but you don't have enough precision in your coordinates so I end up with a blank image (100% exterior).  You need at least 13 digits after the point for 1e-13 pixel spacing (corresponding to 1e-10 radius at 1e3 image size).

Many thanks to both of you! Claude identified the problem right away (well, he knows - he's even written a proof for it): for performance reasons I had omitted the Pythagoras square root for the distance check without squaring the other side. That was rather stupid of me, sorry!

I was assuming that precision artefacts should look different, but I lack real experience in the field. Without being able to find words for it, I even have a feeling of a slight understanding about the reasons the artefacts appear when falsely checking against 2 instead of 4.

I am currently experimenting on sonification of the Mandelbrot set. Yes, I know I am not the first to try/do that. But I wanted to make fractals sound since I first got to know them as an 11th grader in the early 90ies. Neither computers nor I were ready for that task then. Ok, computers definitely more than I was :-D

No apologies needed - thank you very much for your input!
I have a first YT video of my experimental program:

I have noticed that I still have some overlapping spots (not visible in this video) and arbitrarily raised the limit from 4 to 5. Is there any number that is proven to be sufficient? I could just take a 10, it should not make a big performance difference (one or two iterations each) I guess. But on the other hand it would be possible to have more "false positives" at the end of the iterations….

Is there any number that is proven to be sufficient? I could just take a 10, it should not make a big performance difference (one or two iterations each) I guess. But on the other hand it would be possible to have more "false positives" at the end of the iterations….

I use the Douady estimate for polynomial Julia sets that is sufficient in the mathematical sense:
(1 + sum over all coefficient's magnitude)
divided by the highest degree coefficient (Figueireo et al, Images of Julia sets that you can trust, chapter 7).

As the c-value is the degree-0 coefficient, escape radii can be chosen quite differently for different parts of the set, which might speed things up - and if fewer iterations are sufficient for a (theoretically) correct result, the chance for numerical error to overpower the correct answer goes down (useful for degree >= 3).

There are sharper bounds mentioned in the text I've not used.

If by sufficient you mean sufficient for the used numerical type not producing any false escaping/bounded results, that'd be a very interesting question - but I have no answer.

I've currently started using Robert Munafo's f107 double-double implementation, which is about the speed of long double. This might be an option to try instead of arbitrary precision.

Wow, thats a lot of stuff to learn from, thank you very much! I will yet have to understand parts of it, but I probably will :-)
For the time being I've set the value to 4 (magnitude ==2).

When I wrote, that'd not be sufficient, I had mended a wrong (mostly unused) method. As it's not very expensive, I don't need smaller values - the impact would be marginal.