SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.

[aleph0]

While mrflay's perturbation theory paper and the programs it has spawned are great (I use all of them), I noticed there is a small error at the start of the paper. It doesn't affect the utility of what follows in the paper, but it's worth being aware of.

Rather than add unnecessary noise to this thread, I've started a new thread to address it here:
- http://www.fractalforums.com/general-discussion-b77/terms-z0-and-c-in-the-mandelbrotjulia-iteration-formula/

[hapf]

While mrflay's perturbation theory paper and the programs it has spawned are great (I use all of them), I noticed there is a small error at the start of the paper. It doesn't affect the utility of what follows in the paper, but it's worth being aware of.

Rather than add unnecessary noise to this thread, I've started a new thread to address it here:
- http://www.fractalforums.com/general-discussion-b77/terms-z0-and-c-in-the-mandelbrotjulia-iteration-formula/

I don't understand the formula for delta2 in the paper. I get something else.

[hapf]

Question to those of you who use the series approximation. How many percent of the iterations can you skip
on average (without visibly degrading the picture)? What are the best and worst percentages you have seen?

[lycium]

I finally had a proper look at this paper last night, and asked my boss about it today. We both agree, that the "smallness" of the numbers don't really help anything - IEEE floating point stores mantissa and exponent, so it's in a sense "scale invariant". If you wanted to take advantage of the limited range, it would probably involve fixed point arithmetic.

Nevertheless, the real issue I have with this method is that it's not a true acceleration for the same computation. It's a kind of approximation, and the deviation from the "true" result is essentially impossible to quantify since it's a chaotic system. So it's something like apples and oranges comparison, no?

Edit: I also noticed the uncommon domain in the URL (.co.nf), and had to look up where it's from - Norfolk Island! That's pretty remarkable, since there are only about 2000 people there 

[hapf]

I finally had a proper look at this paper last night, and asked my boss about it today. We both agree, that the "smallness" of the numbers don't really help anything - IEEE floating point stores mantissa and exponent, so it's in a sense "scale invariant". If you wanted to take advantage of the limited range, it would probably involve fixed point arithmetic.

Well, the point is that you can calculate the actual images while zooming in far beyond what double usually allows (due to the inability to add a very "small" number to a "big" number) by not adding a "small" number to a "big" number but multiplying "small" numbers with "big" numbers and adding "not too different size" numbers. And it does work indeed very well for many images while others have areas where the double mantissa has not enough bits and rounding errors pile up to the extent that the result is severly distorted. There are alternative reference points for these areas that avoid distortion so the method in principle works for all zoom levels and offers SIGNIFICANT speed ups compared to a brute force arbitrary precision standard approach.

Nevertheless, the real issue I have with this method is that it's not a true acceleration for the same computation. It's a kind of approximation, and the deviation from the "true" result is essentially impossible to quantify since it's a chaotic system. So it's something like apples and oranges comparison, no?

The first formula is exact up to the rounding errors of whatever format you use to compute it. Mathematically it is as exact as the original formula and it computes the same thing. Actually, for deeper zooms it is practically far more exact as the original formula when using the same floating point format because it goes on delivering useful results while the original formula gives just coarse numeric chaos or a constant image. The second formula (series approximation) is inexact and has to be used with care or serious damage is done to the computations. The real remarkable formula for me is the first. The second is gravy for some types of images and better not be overindulged in or you get tummy trouble.  

[Nahee_Enterprises]

    I also noticed the uncommon domain in the URL (.co.nf), and had to look up where it's from - Norfolk Island!
    That's pretty remarkable, since there are only about 2000 people there 

Actually, getting Domain Names under some small country designation usually requires very little money, and they are less likely to be enforced by the various rules and regulations that sometimes happen in other countries.  And sadly, such places are also used by a lot of spammers and bogus web site owners.     
 

[SeryZone]

Hello to all!!! I guess, It's very hard & complexity location:
re 0.250,002,621,568,580,738,997,691,523,223,923,403,858,705,697,470,944,821,494,7
im -0.000,000,006,774,686,923,476,700,530,474,801,910,940,390,679,981,369,231,565,2
Zoom: 1e54
I have started render it.

[hapf]

Hello to all!!! I guess, It's very hard & complexity location:
re 0.250,002,621,568,580,738,997,691,523,223,923,403,858,705,697,470,944,821,494,7
im -0.000,000,006,774,686,923,476,700,530,474,801,910,940,390,679,981,369,231,565,2
Zoom: 1e54
I have started render it.

I hope you have a Petaflop computer if you want to see this region in high res and soon. 
Needs more than 16 Million iterations...

[Kalles Fraktaler]

Question to those of you who use the series approximation. How many percent of the iterations can you skip
on average (without visibly degrading the picture)? What are the best and worst percentages you have seen?

It is very dependent of the location.
Best - all but some 10 of some 100000. That is very deep near -2,0i
Worst - some 2-3 of some 10000000, in a close-up of a deep minibrot

Mrflay says in his paper that series approximation is dependent of the complexity of the image. My non-mathematical expression is that this means the range of iterations in the same image.

[hapf]

It is very dependent of the location.
Best - all but some 10 of some 100000. That is very deep near -2,0i
Worst - some 2-3 of some 10000000, in a close-up of a deep minibrot

Am I reading this correctly?
Best: 100% minus some 10 (e.g. 70-80% or so) of iterations in the range of some 100000?
Worst: 2-3% of iterations in the range of some 10000000 (that must take very long to render even at smaller resolutions)

[SeryZone]

I hope you have a Petaflop computer if you want to see this region in high res and soon. 
Needs more than 16 Million iterations...

I use 50 000 000 iterations. 2x2 AA. If walk - means walk! I fluff that it maybe can renders more than 12 days! I want look to this location!!! I have 8-Core 4GHz AMD

[hapf]

I use 50 000 000 iterations. 2x2 AA. If walk - means walk! I fluff that it maybe can renders more than 12 days! I want look to this location!!! I have 8-Core 4GHz AMD

I don't think it looks fundamentally different from the same region zoomed out to more computation friendly iteration numbers (2 Million or so).

[Kalles Fraktaler]

Am I reading this correctly?
Best: 100% minus some 10 (e.g. 70-80% or so) of iterations in the range of some 100000?
Worst: 2-3% of iterations in the range of some 10000000 (that must take very long to render even at smaller resolutions)

Series approximation give me 95739 iterations of SeryZone's location, if it requires 50 million it will indeed take some time to render it...

[brainiac94]

The concept is amazingly simple yet so powerful - Words are failing me. Thank you, mrflay, for this method. You even made a Java implementation.. I am speechless.

[hapf]

The concept is amazingly simple yet so powerful - Words are failing me. Thank you, mrflay, for this method. You even made a Java implementation.. I am speechless.

It's quite something, isn't it, especially if one can get rid of the "blobs" in a timely fashion?