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

Warp <war### [at] tagpovrayorg> wrote:
> 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.
>

In practice, however, you are very apt to run into "ugliness" due to povray's
short-cheating on iterations capability before you run into ugliness due to
"mag".

Three years ago, you refused to test code that showed this problem.

http://news.povray.org/povray.advanced-users/thread/%3Cweb.4718d5b659db5e5d40d56c170@news.povray.org%3E/?ttop=337821&to
ff=100

Post a reply to this message

"gregjohn" <pte### [at] yahoocom> wrote:
> Warp <war### [at] tagpovrayorg> wrote:
> >   That doesn't affect the artifacts you get when you zoom beyond the
> > accuracy of double-precision floating point numbers.
> >
>
> In practice, however, you are very apt to run into "ugliness" due to povray's
> short-cheating on iterations capability before you run into ugliness due to
> "mag".
>
> Three years ago, you refused to test code that showed this problem.
>

Link was dead on web version:

http://tinyurl.com/y6yj9kv

Post a reply to this message