Re: Bignum looses precision too fast?

On Jul 24, 11:47 pm, "mensana...@xxxxxxx" <mensana...@xxxxxxx> wrote:
On Jul 24, 2:26?am, mike3 <mike4...@xxxxxxxxx> wrote:





On Jul 23, 10:01 pm, "mensana...@xxxxxxx" <mensana...@xxxxxxx> wrote:

On Jul 23, 10:03?pm, mike3 <mike4...@xxxxxxxxx> wrote:

On Jul 23, 4:34 pm, user923005 <dcor...@xxxxxxxxx> wrote:

On Jul 23, 1:09 pm, mike3 <mike4...@xxxxxxxxx> wrote:

Hi.

I was making a program to deep zoom in fractals using bignum floating
point. But the bignum routines I wrote loose precision too fast -- for
instance one with a magnification of 10^31 with 128-bit arithmetic
does not work -- it needs 160 bits (5 dwords instead of 4 -- the
numbers are stored as strings of 32-bit dwords). Is this a hard limit,
even though 2^-128 ~ 10^-38 not 10^-31? Or am I missing something
(guard digits? rounding?)

Try it with an existing number class and see if you have the same
problem.
Assuming you can do fundamental arithemetic operations, you might look
at this stuff for the other functions:http://www.netlib.org/cephes/128bdoc.html

PS. here's a picture if this will help:

http://img507.imageshack.us/img507/3120/fractalprogramdebugtestka8.png

The left picture, done with the 128-bit mantissa (should be able
to go down to a maximum resolution of ~10^-39,

Doesn't the mantissa of your starting coordinate have 42 decimal
places?
Why would you think 128 bits would work?

It does, but rounding it down to 38 does not have an effect. And
at magnification 10^31 the remaining decimals below 10^-38 are
not going to really matter (that's ten-millionths of the
magnification

How do you determine whether a point is inside
the Mandelbrot set? Under those circumstances,
are you sure that's a valid issue?

The color of the point is determined by how many iterations the
calculation takes to converge. (It is a simple calculation to find
zeros of a simple equation in the complex plain).
If the calculation fails to converge before a given number of
iterations, it is considered to be outside of the set.

He definitely has a numeric problem of some kind with his number
library/class.
The Mandelbrot set has infinite detail, so you can zoom in forever as
long as your math has the precision for it.
Fractint uses arbitrary precision to get the deeper zooms.

.

Relevant Pages

  • Re: demonic numbers !
    ... > corresponding calculation of error intervals. ... Then they're either not doing enough math for rounding errors to ... accumulate or they're not using a wide enough range of magnitudes. ... They don't need more than 53 bits of precision to store those values. ...
    (comp.lang.lisp)
  • =?Utf-8?Q?Re:_I_don=C2=B4t_view_the_value_right?= =?Utf-8?Q?_after_six_decimal_place_in_Exce
    ... You might consider setting the option Tools> Options> Calculation> ... Precision As Displayed. ... final result, not intermediated calculations (subexpressions). ... the workbook first because some changes cannot be undone by simply ...
    (microsoft.public.excel.misc)
  • Re: ROUNDING RESULT OF CALCULATION UP OR DOWN
    ... In one of the calculation rules we had to round to a whole year. ... I keep repeating we need decimal arithmetic in Excel, ... | ??>> the limits of precision? ...
    (microsoft.public.excel.misc)
  • Re: Problem with a small "exercise" code using compiler xlf
    ... going from REAL to DOUBLE PRECISION solved part of the ... In the case of problems like this, negative square roots when ... in the intermediate calculation gives a negative square root. ... one could choose one rounding mode for one part ...
    (comp.lang.fortran)
  • Floating Point , Wide zero etc
    ... The default precision of 4 is used. ... require 6 places for GST calculation. ... The simple rule is never store unconverted data for accounting. ... the binary approximation converts back to ...
    (comp.databases.pick)