Re: Bignum looses precision too fast?

On Jul 25, 11:08 pm, "mensana...@xxxxxxx" <mensana...@xxxxxxx> wrote:
On Jul 25, 10:11?pm, mike3 <mike4...@xxxxxxxxx> wrote:





On Jul 24, 11:32 pm, user923005 <dcor...@xxxxxxxxx> wrote:

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.

Does that thing represent stuff as binary-base internally (Ie. not
binary coded decimal or something like that but binary floating
point (so many bits times some power of 2))? That's what I need --
another library that does binary floating point and then I can
test against it to dx the problem

Have you tried GMP? Does floating point to an
arbitray number of bits.

Yes, I have tried GMP. But GMP's floats are dynamic,
not static, precision, (the number of digits stored can
go up and down) and there does not seem to be
any way to make it static short of pretty much overhauling
it, and I don't like the extra workload.

The thing I'm doing is essentially to create a data type
that works like ordinary "C" "doubles", "floats", "long
doubles", etc. but you can make it as wide as you want.
It doesn't use an "IEEE-style" format but it's reasonably
close. Doubles/floats/etc. do not expand and contract
with use! They don't go from 53 bits to 64 bits and down
again or something like that...

.

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 ... 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 ... 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 ... 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)