From: Daryle Walker (darylew_at_[hidden])
Date: 2005-09-05 12:11:07
On 9/2/05 2:23 PM, "Joel Eidsath" <jeidsath_at_[hidden]> wrote:
> I've used several different arbitrary precision libraries with C++ and I
> have always been somewhat disappointed. And now I'm finally
> disappointed enough to start on my own.
> Here are the attributes that I think a C++ arbitrary precision library
> 0) As much as possible, the library types should be drop-in
> replacements for the built-in types.
> a) This probably means some sort of numeic_limits support. I am
> unclear on the best implementation of this.
I have an attempt at this in the Sandbox CVS. It includes a
"numeric_limits" specialization. Look for the math/big_whole library.
> b) Any automatic type conversions should behave in an obvious
> c) Ease of use may take priority over efficiency.
> 1) The library should be both useful for number theory and a way of
> improving code robustness by minimizing overflow errors.
> 2) It should also provide equivalents of the basic C++ math functions.
> Implementing TR1 functions should be a priority.
Be careful. Many functions return irrational (particularly transcendental)
results. You have to define your cut-off philosophy. You can optionally
make variants of the math functions that include a parameter for a cut-off
> 3) As well as arbitrary precision, it should provide error range math:
> 2.00 * 2.00 is not generally the same thing as 2.0 * 2.0
Will this be a separate class? A pure computation class doesn't have to
make this kind of distinction.
> 4) It should use fast algorithms for multiplication and division, but
> instead of trying to compete with other libraries in computation speed
> (GMP uses hand-coded assembly in places), it should concentrate on code
> portability and ease of extension.
> 5) I do not envision any fancy memory management. The "big int" class
> will probably use a std::vector<int> to store it's implementation data.
What about std::deque?
> 6) Providing math functions beyond those already in C++ will not be a
> a) GCD will be at least one exception to this.
Will access to the internals improve the implementation of GCD? If not, we
already have GCD and LCM functions in Boost.
> 7) It should work well with other Boost libraries where possible.
> 8) Divide by zero errors for integers should be handled with an exception.
> 9) Precision for rational numbers may be set as a static member
> variable or it may not. In the second case, expressions involving
> rational numbers of different.
Your rational numbers would be distinct from boost::rational<your::integer>?
What would be the advantage?
> 10) Drop-in algorithm replacement for various operations might be a
> nice feature.
> Comments, suggestions, desired features? Some of the parts of this list
> are off the top of my head, so feel free to suggest changes.
-- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk