High!

Inspired by my loved one who is a true fractal aficionado (he also wrote 
his own fractal generation tool, using QBasic!), I reactivated an old 
mandelbrot zoom script from 2001 (back then using POV-Ray 3.1). But 
otherwise than stated in the manual, the calculation ends not at a 10^33 
magnification, but merely at about 10^14, the pattern starts to look 
"blocky".

Is it possible to increase this calculation depth without hacking 
POV-Ray's source code? If not, would it be legal according to the POV 
license to do so?

See you in Khyberspace!

Yadgar

Post a reply to this message

> But 
> otherwise than stated in the manual, the calculation ends not at a 10^33 
> magnification, but merely at about 10^14, the pattern starts to look 
> "blocky".

  A double-precision floating point value has a 53-bits wide mantissa, which
is able to represent approximately 15 significant digits of accuracy. Thus
the limit you are seeing.

> Is it possible to increase this calculation depth without hacking 
> POV-Ray's source code?

  No. The accuracy of a double-precision floating point number is fixed in
hardware.

> If not, would it be legal according to the POV license to do so?

  You can do whatever modifications you want to it. It's publication which
has its limits.

  Note, however, that you won't be able to increase the accuracy unless you
use a multiple-precision floating point library which calculates the values
in software and will inevitably be extremely slow.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
>   Note, however, that you won't be able to increase the accuracy unless you
> use a multiple-precision floating point library which calculates the values
> in software and will inevitably be extremely slow.

Out of curiosity, while I often see "no, arbitrary-precision floats 
won't be done in POV ever because they're way too slow", it's never 
really indicated just how slow this would be.  Slower than hardware, to 
be sure, but that's not much to go on.  Current *single* CPUs can do in 
seconds what took hours or days fifteen years ago...in software.

I, for one, would be interested in seeing hard number comparisons.

--
Tim Cook
http://empyrean.freesitespace.net

Post a reply to this message

Tim Cook <z99### [at] gmailcom> wrote:
> I, for one, would be interested in seeing hard number comparisons.

  I have first-hand experience. My FunctionParser library currently supports
many floating point and integer types as its basic data type. Among others,
it supports 'double' (which is a 64-bit floating point type which has a 53-bit
mantissa calculated in hardware, and the same that POV-Ray uses for most of
its calculations) as well as multiple-precision software floating point
numbers using the MPFR library.

  I have a comprehensive regression testbed program which runs over a hundred
tests on the library. It can run it with all the supported data types or
with just one. It uses 80 mantissa bits for the MPFR floating point values
(which is about 24 significant digits of accuracy, compared to the about 15
of double-precision floating point numbers; not much larger, but the speed
of the MPFR library decreases as more mantissa bits are used).

  Running all the current tests for the 'double' in my computer type takes
about 1.7 seconds, while running the same tests for the 80-bits-mantissa
MPFR type takes about 5 minutes.

  (Of course this tests many mathematical functions which wouldn't be
necessary to calculate the Mandelbrot set, which only requires additions
and multiplications, and the difference in speed would most probably not
be as drastic with those, but it gives a good idea of the overall difference
in speed when a wide range of mathematical functions and operations is used.)

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
>   I have a comprehensive regression testbed program which runs over a hundred
> tests on the library. It can run it with all the supported data types or
> with just one. It uses 80 mantissa bits for the MPFR floating point values
> (which is about 24 significant digits of accuracy, compared to the about 15
> of double-precision floating point numbers; not much larger, but the speed
> of the MPFR library decreases as more mantissa bits are used).
> 
>   Running all the current tests for the 'double' in my computer type takes
> about 1.7 seconds, while running the same tests for the 80-bits-mantissa
> MPFR type takes about 5 minutes.

Not sure if this is delving into the same direction as those GPU-POV 
threads, but is there an effective way to split off and only use the 
arbitrary-precision math when it falls outside the hardware capability?

--
Tim Cook
http://empyrean.freesitespace.net

Post a reply to this message

Tim Cook <z99### [at] gmailcom> wrote:
> Not sure if this is delving into the same direction as those GPU-POV 
> threads, but is there an effective way to split off and only use the 
> arbitrary-precision math when it falls outside the hardware capability?

  How do you tell when to "split off"?

  For example, how many mantissa bits are necessary to "accurately" depict
the number 0.1? (Note that 0.1 cannot be represented accurately by any
amount of mantissa bits, similarly to how 1/3 cannot be represented by
any amount of decimals in base-10 representation.)

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
> Tim Cook <z99### [at] gmailcom> wrote:
>> Not sure if this is delving into the same direction as those GPU-POV 
>> threads, but is there an effective way to split off and only use the 
>> arbitrary-precision math when it falls outside the hardware capability?
>   How do you tell when to "split off"?
> 
>   For example, how many mantissa bits are necessary to "accurately" depict
> the number 0.1? (Note that 0.1 cannot be represented accurately by any
> amount of mantissa bits, similarly to how 1/3 cannot be represented by
> any amount of decimals in base-10 representation.)

Hmm...have a render argument flag as to whether to use 
arbitrary-precision or not?

--
Tim Cook
http://empyrean.freesitespace.net

Post a reply to this message

Tim Cook <z99### [at] gmailcom> wrote:
> Hmm...have a render argument flag as to whether to use 
> arbitrary-precision or not?

  In order for the double-version not to suffer any speed overhead, you
would basically have to have two different versions of POV-Ray, one using
double and the other using multiple-precision floating point. So you could
just as well have to separate binaries. No need for a flag.

-- 
                                                          - Warp

Post a reply to this message

The algorithm in povray arbitrarily shuts down with an iterations above 32767.

It could let you go to higher resolution with higher counts; it seems an
abritary choice.

Post a reply to this message

gregjohn <pte### [at] yahoocom> wrote:
> The algorithm in povray arbitrarily shuts down with an iterations above 32767.

> It could let you go to higher resolution with higher counts; it seems an
> abritary choice.

  That doesn't affect the artifacts you get when you zoom beyond the
accuracy of double-precision floating point numbers.

-- 
                                                          - Warp

Post a reply to this message