Re: Bignum looses precision too fast?

On Jul 26, 2:35 pm, "mensana...@xxxxxxx" <mensana...@xxxxxxx> wrote:
On Jul 26, 2:03 pm, mike3 <mike4...@xxxxxxxxx> wrote:





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.

Are you sure about that?

<quote>
mpf_t variables, in the current implementation, use a fixed
amount of space, determined by the chosen precision and allocated
at initialization, so their size doesn't change.
</quote>

But you get a default if the precision is not specified. For example,
take your starting point

x = gmpy.mpf('-1.931860555385885640047740549050717469620245')
gmpy.getprec(x)

64

the precision is 64 bits. But look what happened to the number:

x

mpf('-1.93186055538588564005e0')

Loss of precision (the default 64 bits wasn't enough to accomodate
the literal that was typed in. Had I specifically asked for 200 bits
of precision,

y = gmpy.mpf('-1.931860555385885640047740549050717469620245',200)
gmpy.getprec(y)

224

I actually got a few more bits (which shouldn't matter). But this time
there is no loss of precision:

y

mpf('-1.931860555385885640047740549050717469620245e0',200)

Keep in mind that
<quote>
All calculations are performed to the precision of the destination
variable. Each function is defined to calculate with "infinite
precision" followed by a truncation to the destination precision,
but of course the work done is only what's needed to determine a
result under that definition.
</quote>
so you need to be sure all variables have been initialised to the
same precision.


But based on examining how much is stored in memory the Gmp
library seems to add extra bittage unlike "doubles" do. I need
something that doesn't do that. That way I can absolutely find or
rule out all potential bugs in the implementation of the arithmetic
algorithms.

.

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