On 9/2/05 2:23 PM, "Joel Eidsath" <jeidsath@gmail.com> 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 needs:
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 manner. 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 specification.
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 priority. 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