SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.

[Kalles Fraktaler]

If the reference point is in a minibrot it can't have too few iterations compared to other points in the image unless the general maxiter for the image is set too low.

But these high iterations might be too deep and not reachable from a double in the blob's area. On the same level as the blob, the reference point in the minibrot have fewer iterations than the blob area.

I have not seen such a case yet but I don't do 'very' deep zooms. Does anyone have an example for this that is not zoomed in very deep?

It's not hard to find them, just zoom near but not inside a minibrot and then center the zoom to find another minibrot. When the pattern of the first minibrot is repeated and doubled, you will usually get blobs if you go deep enough.
A double doesn't handle more than about some 20 decimals correct, so it makes sense that you don't see this unless you go twice (hmm... I mean the power of 2) as deep as that, i.e deeper than 1e40.

An example

Code:

Re: -1.99213324664384300764723417856669787618617795243197913361627207256668566332812499
Im: -0.00000000000000000000058532350873080880109479518491239351181421822858756776666666

This location is close to a minibrot at 1e21 and the minibrot with the reference point is located at 1e47.
The blobs are visible at 1e35, 4e4, and 8e44.

[hapf]

But these high iterations might be too deep and not reachable from a double in the blob's area. On the same level as the blob, the reference point in the minibrot have fewer iterations than the blob area.

If maxiter is such that it's high enough for the picture when no precision issues occur then the reference point in the minibrot has maxiter iterations. Anything else in the picture not in the Mandelbrot set will escape before maxiter is reached. So if in a blob maxiter is reached maxiter is too low for the picture or it's an effect of rounding errors (e.g. pixels in the blob would have escaped before maxiter is reached if sufficient precision was used). So are you saying pixels in the blob not only become indistinguishable from each other due to lack of precision but also continue to not escape although they should have escaped before maxiter is reached? If so, do they all escape together at the same time with a higher maxiter?

It's not hard to find them, just zoom near but not inside a minibrot and then center the zoom to find another minibrot. When the pattern of the first minibrot is repeated and doubled, you will usually get blobs if you go deep enough.
A double doesn't handle more than about some 20 decimals correct, so it makes sense that you don't see this unless you go twice (hmm... I mean the power of 2) as deep as that, i.e deeper than 1e40.

An example

Code:

Re: -1.99213324664384300764723417856669787618617795243197913361627207256668566332812499
Im: -0.00000000000000000000058532350873080880109479518491239351181421822858756776666666

This location is close to a minibrot at 1e21 and the minibrot with the reference point is located at 1e47.
The blobs are visible at 1e35, 4e4, and 8e44.

Thanks for the location. I will have a look when I start zooming this deep.
How do you automatically decide on a reference point and make sure it iterates to maxiter before you process the picture?

[Kalles Fraktaler]

How do you automatically decide on a reference point and make sure it iterates to maxiter before you process the picture?

I just select the pixel in the center as reference and add references later to correct the glitches.
But for the example, I zoomed to the minbrot at 1e47 and "locked" the reference point there and then zoomed out again.
Here is a picture of the location I mentioned, zoomed to 1e35 and with the reference point in the 1e47 minibrot, with no additional reference points.

[Kalles Fraktaler]

So are you saying pixels in the blob not only become indistinguishable from each other due to lack of precision but also continue to not escape although they should have escaped before maxiter is reached? If so, do they all escape together at the same time with a higher maxiter?

No, they escape at the same iteration but not necessary at the highest iteration. There might be other parts in the same picture, not belonging to a blob, with higher iterations than the blob. So it is a challenge to detect the blobs automatically...

[hapf]

I have just started deep zooms with the delta formula and use automatic reference point assignment. So far no blobs. I also added the distance measure computation with a delta formula. I want it for colouring purposes. And it might come handy for other things. 
Needs a lot more testing, though, to see if blobs happen or not.
The series extension I won't consider for now since its speedup is limited to about half the time compared to without. ?

[Kalles Fraktaler]

The series extension I won't consider for now since its speedup is limited to about half the time compared to without. ?

If you look at time comparisons in the thread about "Kalles Fraktaler" you'll see that the speedup was 10 times for the "tick-tock" location.
Series approximation let you skip iterations in the delta function. The amount of iterations that can be skipped is dependent on the image's complexity, i.e. iteration span, rather than depth or the maximum iteration count.

The automatic assignment of reference point sounds interesting though. Is it possible to compare points without calculating them with full precision?

[hapf]

If you look at time comparisons in the thread about "Kalles Fraktaler" you'll see that the speedup was 10 times for the "tick-tock" location.
Series approximation let you skip iterations in the delta function. The amount of iterations that can be skipped is dependent on the image's complexity, i.e. iteration span, rather than depth or the maximum iteration count.

How do you decide how many iterations to skip?

The automatic assignment of reference point sounds interesting though. Is it possible to compare points without calculating them with full precision?

To be safe so far I have done all reference point calculations with my default arbitrary precision (1000 bits). Double precision won't work for my approach.

[hapf]

I just select the pixel in the center as reference and add references later to correct the glitches.
But for the example, I zoomed to the minbrot at 1e47 and "locked" the reference point there and then zoomed out again.
Here is a picture of the location I mentioned, zoomed to 1e35 and with the reference point in the 1e47 minibrot, with no additional reference points.

I get this region when using 1.0E-34 as size in the real direction.
I can see the region is critical. Depending on where you look the dominant period modulating the iterations changes several times hopping from from center to center in the picture to centers far away from the picture. And the center of the picture is close to zero for i and close to 2 for r which combines very far away values. Worst case behaviour for the deltas, I guess. I can see clearly distortions for the distance measure based on deltas. These get distorted more quickly than iterations since the formula is more complicated. For iterations it depends which reference point is chosen. I have to look into this more to see if one point works properly for all the picture and which one it is.

[Kalles Fraktaler]

How do you decide how many iterations to skip?

I do as mrflay, I compare the values from the approximation functions with the pertubation function on a couple of pixels. I select the 4 corners.

I have to look into this more to see if one point works properly for all the picture and which one it is.

I believe that's not possible.

[hapf]

I do as mrflay, I compare the values from the approximation functions with the pertubation function on a couple of pixels. I select the 4 corners. I believe that's not possible.

I use this location for now (left lower corner and right upper corner)
-1.9921332466438430076472341785666978808861779524319777569397215373725755380248565573828125
-0.000000000000000000000585323508730791567761461851578556877376388157622575720310458828125
-1.99213324664384300764723417856669786998617795243197362691006993179024516211505125953125
-0.000000000000000000000585323508730780667761461851579977962847908357994317968845615078125
It has distortions like yours (it's zoomed in a bit into yours). I think I found a point that works for all of it. I need to verify my theory why and if this point works and how to find it automatically (found it 'manually').
Going back to your original location:
So far what I see is that a large part of the picture has a 'dominant' period from a minibrot far away. Using that minibrot as reference renders pretty much the whole picture useless. If one uses minibrots in the picture the higher the dominant period they belong to the better the results...

[Kalles Fraktaler]

I think I found a point that works for all of it. I need to verify my theory why and if this point works and how to find it automatically (found it 'manually'). To be continued...

Yes you are right, for the location above it is possible to render the image without blobs from one reference point. That is because the center do not have any distinct pattern.
But this location (the top on the page) is not possible to render with one reference point only: http://www.fractalforums.com/images-showcase-(rate-my-fractal)/other-worlds'-frightening-digital/
If you use the center, you will have blobs around, if you use the center of one of these blobs, all these blobs are solved but instead the center becomes a blob.
Therefore I think it is impossible to have only one reference point for all pictures.
But I would be glad if you could prove that I am wrong and show how to find the best reference point automatically

[knighty]

If I understand correctly, the blobs happen in regions where the magnitude of the derivative becomes too small (or too big?) at some iteration(s). Taking the minimum (and the maximum?) of would give some information about the areas where floats are no more sufficient and where blobs occure.

Using the notation of the pdf document, the derivative of :


wrt is :



Could anyone verify? (I can't do it myself  )

[hapf]

If I understand correctly, the blobs happen in regions where the magnitude of the derivative <Quoted Image Removed> becomes too small (or too big?) at some iteration(s). Taking the minimum (and the maximum?) of <Quoted Image Removed> would give some information about the areas where floats are no more sufficient and where blobs occure.
Using the notation of the pdf document, the derivative of <Quoted Image Removed> :
<Quoted Image Removed>
wrt <Quoted Image Removed> is :
<Quoted Image Removed>
<Quoted Image Removed>

Could anyone verify? (I can't do it myself  )

I'll test it later today. A blob could be a region where the derivative becomes bigger than some threshold, I guess. But it's not conclusive at first sight. The formula for the delta is precise. The blobs are due to rounding errors, not fast changes of the deltans as a function of delta zero. The question is how are rounding errors correlated with this derivative. Possibly not.

[knighty]

I just noticed that the derivative I gave in my previous post is just the standard derivative wrt c. lol! after thinking a little about it, it is just obvious.

@hapf: Thank you in advance .

[knighty]

@hapf: You are right. It seems that derivative have nothing to with the blobs. The areas where the derivative vanishes are always inside de Mset.
Another try  (remembering a article about floating point accuracy issues somewhere in the net): cancellation which induce accuracy loss happens usually when subtracting two numbers which difference is very small.
In the formula:

if:

or:

(which is equivalent)
we will loose significant digits.
This phenomenon may occure several times in the loop implying that the numerical errors accumulates. Maybe there is also some kind of resonance. I don't know though how these errors accumulate.
(Ok! I have checked this by using only double floats).