About precision of doubles

[louwin]

I'm a retired programmer (assemblers, COBOL and BASIC mainly). A total newbie in C++.

Rather than use one of the few excellent programs available I'd like to write my own 

"double" variables SHOULD go to E308 so could someone please explain to me why I can only "zoom" to about 1.0E13 before it gets all "blocky"?

I even tried "long double" and that only went to about 2.0E18   

My research seems to suggest this is normal but I'd like to know why?

This is the code I'm using....

Code:

int MAXI, maxIterations;
long double zoom, moveX, moveY;
long double newRe, newIm, oldRe, oldIm;
long double pixelX, pixelY;

for (zoom = 1.0E16L; zoom <= 1.0E18L; zoom *= 1.5) {
	for (int y = heightM; y >= 0; y--) {
		pixelY = (y - halfheight) / (zoom * halfheight) + moveY;
		for (int x = 0; x < width; x++) {
			pixelX = /*whscale*/1.5 * (x - halfwidth) / (zoom * halfwidth) + moveX;
			newReal = newImaginary = oldReal = oldImaginary = 0; 
			for (i = 0; i < maxIterations; i++) {
				oldReal = newReal; oldImaginary = newImaginary;
				newReal = oldReal * oldReal - oldImaginary * oldImaginary + pixelX;
				newImaginary = 2 * oldReal * oldImaginary + pixelY;
				if ((newReal * newReal + newImaginary * newImaginary) > 4) break;
			}
			if (i < maxIterations) {
				colour = Colours[i % 251];
			} else {
				colour = BLACK;
			}
			SetPixel(hdc, x, y, colour);
		}
        }        
}

For simplicity I editted out extraneous details like writing bitmaps etc 

[quaz0r]

because unfortunately the mandelbrot equation is limited by the mantissa precision, not the exponent.    on the other hand, the perturbation mandelbrot equation, should you choose to go down that rabbit hole, is mostly limited by the exponent, which is most fortunate indeed.  

[louwin]

Thanks for your response   

But bear with me (NEWBIE!) but

Doesn't the mantissa just hold some digits and the exponent the multiplier or divider? If the mantissa "fills up" don't you just add or subtract 1 from the exponent and carry on?

Please explain (in newbie terms) or please provide me a link to the explanation   

[quaz0r]

well the problem is that C requires more and more mantissa as you go deeper.  basically when you are at 10^N C needs around N digits of mantissa.  if you were just doing Z² maybe it would only be limited by the exponent, but since you add C each iteration you are limited by C needing to have all its digits.

[ciric50]

Maybe this will help.

When you're zoomed out, let's say you're looking at values on the x axis something like -2 to +2, so the the range is 2 - (-2) = 4. As you zoom in at some point, the edge values on the x axis get closer and closer together, say 1.00002 to 1.00003, for a range of 1.00003 - 1.00002 = 0.00001. The difference in values is very small. When you zoom in to range values that are very close together, the difference can't be done accurately without high precision. For example 1.00000000000000002 to 1.00000000000000003 in double precision won't work, because the difference between them is less than the smallest number that double precision can represent.

Intuitively it seems like double precision should be more than enough for most calculations (and it is) but in the world of fractals you bump into the precision limitation fairly quickly as you zoom in.

There is a pdf around somewhere with the title "Superfractalthing Maths" where the author explains a technique he found where double precision can be used for these kinds of calculations.

[louwin]

Thanks for that VERY informative response ciric50  

I suppose that also explains why going to "long double" only increased the zoom range by about 100,000....        I was expecting, like, another 30 zeroes? But, as quaz0r suggested, going from 64 bits to 80 bits the mantissa only increases by a few bits   

Now to research VS215 and the Intel Compiler for Quad precision.  Putting off the move to pertubation and arbitary precision        

[quaz0r]

i dont know if using the builtin float128 or float256 types is even worth it compared to just using mpfr.  gmp/mpfr is written to be as efficient as possible, including the utilization of explicit vectorization, which could very well make it the best choice compared to some cheap softfloat implementation.

there is a handy c++ wrapper for mpfr called mpreal:  https://bitbucket.org/advanpix/mpreal/downloads?tab=tags

there is also an old thing called the qd library which gives some sort of supposedly efficient implementation of double-double and quad-double.  internally it is implemented as multiple doubles.

[louwin]

Thanks for the mpreal.h suggestion quaz0r. It DOES look interesting.... Have you actually tried it with VS2015 or the like?

I get errors with the embedded #include mpfr.h within mpreal.... commenting it out goes a bit further

//#include <mpfr.h>

But then I get lots of

C:UsersLouisDocumentsVisual Studio 2015ProjectsProjTechProjTech../mpreal.h(365): error : identifier "mp_rnd_t" is undefined
1>        friend const mpreal tan(const mpreal& v, mp_rnd_t rnd_mode);
1>                                                                                    ^

errors?

Nobody else seems to have complained so it could just be me (newbie!?)....

Thanks again....

[Adam Majewski]

You can also try mpc :
https://pl.wikibooks.org/wiki/Programowanie_w_systemie_UNIX/MPC

if you want to try linux you can here find info about installations

https://pl.wikibooks.org/wiki/Programowanie_w_systemie_UNIX/MPFR
https://pl.wikibooks.org/wiki/Programowanie_w_systemie_UNIX/GMP

and here are about perturbation
https://en.wikibooks.org/wiki/Fractals/Iterations_in_the_complex_plane/Mandelbrot_set#Perturbation_theory

HTH
Adam

[quaz0r]

hmm well mpreal.h is a c++ wrapper for mpfr.h so you need mpfr to be available and working   i know people use mpreal with microsoft compiler but im not sure what the particulars are.