only gives an error using a 32-bit windows 7 laptop.

Java Plug-in 10.17.2.02
Using JRE version 1.7.0_17-b02 Java HotSpot(TM) Client VM
User home directory = C:\Users\Basje
----------------------------------------------------
c:   clear console window
f:   finalize objects on finalization queue
g:   garbage collect
h:   display this help message
l:   dump classloader list
m:   print memory usage
o:   trigger logging
q:   hide console
r:   reload policy configuration
s:   dump system and deployment properties
t:   dump thread list
v:   dump thread stack
x:   clear classloader cache
0-5: set trace level to <n>
----------------------------------------------------
   Match: beginTraversal
Match: digest selected JREDesc: JREDesc[version 1.6+, heap=268435456-4294967296, args=null, href=http://java.sun.com/products/autodl/j2se, sel=false, null, null], JREInfo: JREInfo for index 0:
    platform is: 1.7
    product is: 1.7.0_17
    location is: http://java.sun.com/products/autodl/j2se
    path is: C:\Program Files\Java\jre7\bin\javaw.exe
    args is:
    native platform is: Windows, x86 [ x86, 32bit ]
    JavaFX runtime is: JavaFX 2.2.7 found at C:\Program Files\Java\jre7\
    enabled is: true
    registered is: false
    system is: true

   Match: selecting maxHeap: 4294967296
   Match: selecting InitHeap: 268435456
   Match: digesting vmargs: null
   Match: digested vmargs: [JVMParameters: isSecure: true, args: ]
   Match: JVM args after accumulation: [JVMParameters: isSecure: true, args: ]
   Match: digest LaunchDesc: null
   Match: digest properties: []
   Match: JVM args: [JVMParameters: isSecure: true, args: ]
   Match: endTraversal ..
   Match: JVM args final: -Xmx4g
   Match: Running JREInfo Version    match: 1.7.0.17 == 1.7.0.17
    Match: Running JVM args mismatch: have:<> !satisfy want:<-Xmx4g>

The system has 3 gig but I guess it's the on-board graph card that ruins the party.
Just pasted the info to inform you.
Checking on 64bit machine in a few.

I'm not sure I get this? As I understand it, you calculate a series, Xn, using the standard approach with arbitrary precision floating points. Then you use an approximation with lower precision floats in a neighborhood around Xn.

First, you say that "Equation (1) is important, as all the numbers are 'small', allowing it to be calculated with hardware floating point numbers.". Why does the magnitude of the numbers matter - the series will always stay below 4.0 anyways? I cannot see why the smaller numbers should need less precision.

Secondly, you say "Using equations (1) and (2) means that the time taken rendering Mandelbrot images is largely independent of depth and iteration count". But you still need to calculate a number of series Xn using arbitrary resolution to base your interpolations on, right? Doesn't that mean you get exactly the same dependence on depth and iteration count, and only a linear speedup, because you can estimate the neighborhood faster?

Btw, I tried running your app, but Firefox crashed, and in Chrome I got an NumberFormatExpection for the number "1.024" (probably a localization issue - dot versus comma).

I didn't read the whole theory, maybe I'm completely wrong, but in fact floats are really "more precise" near 0. Because of their structure floating points are not distributed uniformly, they are more dense near zero.

(32 bit) floats are structured this way:

• One bit sign
• 8 bit exponent
• 23 bit mantissa

The fixed size of the mantissa only allows a limited range of digits, but using the exponent we can "move" these digits at a different decimal place (not so easy as moving the point in decimal digits, the point is moved between base-2 digits, but the idea is the same).

So with floats we can not represent numbers like , but it is possible to represent for example which we can call precise since ha more than 30 decimal digits.

Here you can find a good introduction to float representation: http://www.systems.ethz.ch/sites/default/files/file/CASP_Fall2012/chapter3-floatingpoint-1up.pdf. Have a look expecially to slide 20.

(Note: not sure if the numbers can be really represented in base 2... Again I used base 10 because it's easier to understand. It's just an example )

Finally read the document, sound like an interesting trick, but now I'm confused too.

The multiplication of and (or in general of a small number with a number of order 1) still gives a result with the same precision of (mantissas are multiplicated first with full precision, then it's rounded to float precision and the exponents are added). But even if we can say that we have a high precision on the result we still cut away details from , so we can only work on points that can be represented with floats.

Are these multiplications performed with arbitrary precision? They could be faster than a full because one of the two terms has a relatively small number of significant digits, so the advantage of this method can be seen only with big zooms. But I'm only guessing, I'm also interested in some more explaination.

Okay, I got something out of it now. I used the location "deep" in the library in SFT.

Benchmark parameters:

The results:

Software	Calculation time (m:ss)
Fractal extreme	2:52,400
SuperFractalThing	0:11,686

That is a really significant decrease in render time!

incredible results, to make the differences more clear, can you exactly render same resolutions, and then using the same colormap, e.g. 256 grayscales that repeat, and then subtract the images from eachother to show the errors ?