New Topic/Question
Reply
Hi
I have a workmate who is trying to code a differential bio-physical model and has into a problem where 'double's don't go small enough to hold one of the inputs. We are considering just multiplying everything up by a factor of 10^300 the dividing the answer but before we attempt that is there any other way we could solve this? As far as I know doubles are about as precise as its possible to go (.NET).
1 Replies - 1169 Views - Last Post: 25 March 2010 - 04:03 PM
MultiQuoteReplies To: Number Too Small For Double
#2
r.stiltskin
- D.I.C Lover
-
Reputation: 2034
- Posts: 5,436
- Joined: 27-December 05
Re: Number Too Small For Double
Posted 25 March 2010 - 04:03 PM
If that will provide adequate precision it sounds like the easiest solution.
Alternatively you might want to look into the Gnu Multiple Precision arithmetic library: (GMP)
From the GMP online manual:
Alternatively you might want to look into the Gnu Multiple Precision arithmetic library: (GMP)
From the GMP online manual:
Quote
7 Floating-point Functions
GMP floating point numbers are stored in objects of type mpf_t and functions operating on them have an mpf_ prefix.
The mantissa of each float has a user-selectable precision, limited only by available memory. Each variable has its own precision, and that can be increased or decreased at any time.
The exponent of each float is a fixed precision, one machine word on most systems. In the current implementation the exponent is a count of limbs, so for example on a 32-bit system this means a range of roughly 2^-68719476768 to 2^68719476736, or on a 64-bit system this will be greater. Note however mpf_get_str can only return an exponent which fits an mp_exp_t and currently mpf_set_str doesn't accept exponents bigger than a long.
Each variable keeps a size for the mantissa data actually in use. This means that if a float is exactly represented in only a few bits then only those bits will be used in a calculation, even if the selected precision is high.
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.
The precision selected for a variable is a minimum value, GMP may increase it a little to facilitate efficient calculation. Currently this means rounding up to a whole limb, and then sometimes having a further partial limb, depending on the high limb of the mantissa. But applications shouldn't be concerned by such details.
The mantissa in stored in binary, as might be imagined from the fact precisions are expressed in bits. One consequence of this is that decimal fractions like 0.1 cannot be represented exactly. The same is true of plain IEEE double floats. This makes both highly unsuitable for calculations involving money or other values that should be exact decimal fractions. (Suitably scaled integers, or perhaps rationals, are better choices.)
mpf functions and variables have no special notion of infinity or not-a-number, and applications must take care not to overflow the exponent or results will be unpredictable. This might change in a future release.
Note that the mpf functions are not intended as a smooth extension to IEEE P754 arithmetic. In particular results obtained on one computer often differ from the results on a computer with a different word size.
GMP floating point numbers are stored in objects of type mpf_t and functions operating on them have an mpf_ prefix.
The mantissa of each float has a user-selectable precision, limited only by available memory. Each variable has its own precision, and that can be increased or decreased at any time.
The exponent of each float is a fixed precision, one machine word on most systems. In the current implementation the exponent is a count of limbs, so for example on a 32-bit system this means a range of roughly 2^-68719476768 to 2^68719476736, or on a 64-bit system this will be greater. Note however mpf_get_str can only return an exponent which fits an mp_exp_t and currently mpf_set_str doesn't accept exponents bigger than a long.
Each variable keeps a size for the mantissa data actually in use. This means that if a float is exactly represented in only a few bits then only those bits will be used in a calculation, even if the selected precision is high.
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.
The precision selected for a variable is a minimum value, GMP may increase it a little to facilitate efficient calculation. Currently this means rounding up to a whole limb, and then sometimes having a further partial limb, depending on the high limb of the mantissa. But applications shouldn't be concerned by such details.
The mantissa in stored in binary, as might be imagined from the fact precisions are expressed in bits. One consequence of this is that decimal fractions like 0.1 cannot be represented exactly. The same is true of plain IEEE double floats. This makes both highly unsuitable for calculations involving money or other values that should be exact decimal fractions. (Suitably scaled integers, or perhaps rationals, are better choices.)
mpf functions and variables have no special notion of infinity or not-a-number, and applications must take care not to overflow the exponent or results will be unpredictable. This might change in a future release.
Note that the mpf functions are not intended as a smooth extension to IEEE P754 arithmetic. In particular results obtained on one computer often differ from the results on a computer with a different word size.
This post has been edited by r.stiltskin: 25 March 2010 - 04:03 PM
Was This Post Helpful?
0
Page 1 of 1
| 