Re: Bignum looses precision too fast?

On Jul 23, 8: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, but the magnification
factor is only 10^31...) looks strange. When the precision runs out
with ordinary "doubles" or similar we either get a single color or it
becomes pixelated like blowing up a bitmap too far (quantization
error).
But the picture on the left looks like the static from your TV tuned
to a
dead channel (although patterned somewhat and with the center
line (zero imaginary component) bright).

The one on the right shows the same calculation done with a 160-bit
mantissa (5 dwords and should go down to near 10^-49. Mag. factor is
still 10^31.). That is what it is _supposed_ to look like.

What could be the problem? I'd thought of several things but none
of them seemed to be it. I thought about the decimal converter but
that doesn't seem to make sense since it's only used once to convert
the coordinates input to the program -- if it screws up you'll just
see a different part of the fractal, not this. It seems that my
arithmetic routines aren't squeezing all the precision they could
out of the numbers (otherwise it would quantize when you hit the
limit)
What sort of error could do this and how exactly could I test for it?

Take your number library and feed it to Paranoia. There is a version
in here for 100 digit math:
http://www.moshier.net/qlib.zip
You should be able to generalize it.
You could also take one of the classic versions and change the
fundamental types, if you have a drop-in replacement number class.

I guess that it will tell you what is wrong with it.

.

Relevant Pages

  • Re: Bignum looses precision too fast?
    ... But the bignum routines I wrote loose precision too fast -- for ... instance one with a magnification of 10^31 with 128-bit arithmetic ... The left picture, done with the 128-bit mantissa (should be able ... When the precision runs out ...
    (comp.programming)
  • Re: Bignum looses precision too fast?
    ... But the bignum routines I wrote loose precision too fast -- for ... instance one with a magnification of 10^31 with 128-bit arithmetic ... When the precision runs out ... binary coded decimal or something like that but binary floating ...
    (comp.programming)
  • Re: Bignum looses precision too fast?
    ... But the bignum routines I wrote loose precision too fast -- for ... instance one with a magnification of 10^31 with 128-bit arithmetic ... When the precision runs out ... binary coded decimal or something like that but binary floating ...
    (comp.programming)
  • Re: Bignum looses precision too fast?
    ... But the bignum routines I wrote loose precision too fast -- for ... The left picture, done with the 128-bit mantissa (should be able ... When the precision runs out ...
    (comp.programming)
  • Re: Bignum looses precision too fast?
    ... instance one with a magnification of 10^31 with 128-bit arithmetic ... calculation takes to converge. ... The Mandelbrot set has infinite detail, so you can zoom in forever as ... long as your math has the precision for it. ...
    (comp.programming)