Re: Bignum looses precision too fast?

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?

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?- Hide quoted text -

- Show quoted text -


.

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 ... The left picture, done with the 128-bit mantissa (should be able ... When the precision runs out ...
    (comp.programming)
  • Re: QI and MQ Coder: First real-life experiences
    ... > is used to align the mantissa? ... If you look at SWI as a floating point number, ... So for that concept of "precision", ... The SW exponent, of course, as shown e.g. in EncDec.c, function ...
    (comp.compression)
  • Re: Extending floating point precision
    ... If you round one segment you ... the representation is binary, ... once the lower mantissa bits ... upon whose precision the precision of the FP depends. ...
    (comp.arch.embedded)
  • Re: What are the minimum numbers of bits required to represent C std float and double components?
    ... I guess the standards were written to accommodate some ... mantissa sizes to accurately mirror the C standard minimum widths. ... 8 bits for exponent, ... You need 36.54 bits to get 10 digit precision. ...
    (comp.lang.c)