Re: [boost] Interest in an arbitrary precision library?

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