Working with big, big numbers

Started by
15 comments, last by silverphyre673 18 years, 11 months ago
I'm working on a school project, doing a simulation of planetary gravity in c++ as a physics project. I have the whole thing figured out, except for this problem: the numbers involved in the equation that calculates force due to gravity range from very tiny (6.67 * 10^-11) to HUGE (mass of the sun is 1.991 * 10^30). I obviously can't use a double, because the mantissa keeps it from having the neccesary accuracy. Therefore, I was wondering if anyone knows of a library or something with huge numbers that have perfect accuracy, or, better yet, tips on making my own. The only idea I've had for making it on my own is to take like 4 unsigned longs, and then combine the bits somehow into one huge number. Unfortunately, I don't know how this works. If someone knows of a better way, please let me know. Until then, or someone posts a library I can use, its GOOGLE TIME!
my siteGenius is 1% inspiration and 99% perspiration
Advertisement
I've never used it, but I've heard the Bignum/GMP library mentioned in answer to this sort of question.


jfl.
I think using an array of longs would be a good way to go.
Poking around the internet I dug up something Promising:

http://sourceforge.net/projects/libmp/

MP stands for 'Multiprecision'.

"This is a library of classes and functions to be used to abstract arbitrarily large integer and floating-point numbers in C++. All standard operators are overloaded so the user is able to substitute "mpi" for "int" and "mpf" for "double" to use."

Sounds good to me. Hope it helps.

--Mark
How does the mantissa keep it from having the required accuracy? You can get up to 19 significant digits with long doubles, probably greater than the constants you'll be using. I say this having written some physics simulations myself.
Based upon what he said, he needs at least 41 digits as he is spanning at least 41 orders of magnitude
Brendan"Mathematics is the Queen of the Sciences, and Arithmetic the Queen of Mathematics" -Gauss
Quote:Original post by Punty50
Based upon what he said, he needs at least 41 digits as he is spanning at least 41 orders of magnitude
I doubt any of the constants have 41 significant digits, and you don't need to store but a few non-significant digits because most of them are meaningless anyways.
"Walk not the trodden path, for it has borne it's burden." -John, Flying Monk
Quote:I_Smell_Tuna I think using an array of longs would be a good way to go.


Nope. Think about it - I assume you are talking about adding them together. A number in a programming language is actually a number in base 2 - for a char (1 byte, 8 bits, max deci value of 255) the number 7 would be represented as:

0000 0111

Now, for simplicity, you could add a bunch of longs together. This would, however, be terribly inefficient. Consider an array of chars (I don't want to write like four 32-digit binaries!)

By your suggested method, you could have the number 256 (one greater than the max value of a char) by doing this:

1111 1111 + 0000 0001

By this method, the two char method has a max value of 510.

However, you could accomplish the same thing using a short int (16 bits).

0000 0001 0000 0001

Also, this would have a maximum value of 2^16, much, much greater than 510!

So what I'm looking for is a way to combine the bits of several long integers, rather than adding them together.

Quote:
Punty50 Based upon what he said, he needs at least 41 digits as he is spanning at least 41 orders of magnitude


Exactly.

And finally, to the two who posted the libs, thanks. I'll check them out. And, Tuna: no harm intended :P
my siteGenius is 1% inspiration and 99% perspiration
In general, the exponent codes most of the magnitude, not the mantissa. The one exception is with denormal floats.
.
Quote:Original post by silverphyre673
the numbers involved in the equation that calculates force due to gravity range from very tiny (6.67 * 10^-11) to HUGE (mass of the sun is 1.991 * 10^30). I obviously can't use a double, because the mantissa keeps it from having the neccesary accuracy.


Are you sure? I ran a simple test:

double d1 = 6.67E-11;
double d2 = 1.991E30;
Console.WriteLine(d1 * d2);

Which produced 1.327997E+20, which is about right. You might want to prototype some of the equations/magnitudes involved to see if your statement is really true.

This topic is closed to new replies.

Advertisement