Boost logo

Boost :

From: Lucas Galfaso (lgalfaso_at_[hidden])
Date: 2005-09-02 18:49:54


"Joel Eidsath" <jeidsath_at_[hidden]> wrote in message
> 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.

You are not the only one, I started and completed my own implementation of
big ints based, somehow, on the same reasons.

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

Not clear to me on how are you planning on doing this, but if you are only
thinking, but I can not say that I fully agree. Arbitrary precision is just

> b) Any automatic type conversions should behave in an obvious
> manner.

just like C++ ;-)

> c) Ease of use may take priority over efficiency.

Do not agree. You should have ease of use _and_ efficiency. Modern C++
techniques allow for this.

> 1) The library should be both useful for number theory and a way of
> improving code robustness by minimizing overflow errors.

It is not clear to me what you mean by "useful for number theory". You want
the library to handle Z[sqrt(2)](log(2)) arbitrarily good? (this question is
not rhetoric)

> 2) It should also provide equivalents of the basic C++ math functions.
> Implementing TR1 functions should be a priority.

90% agree. Priorities always change.

> 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

Do not fully understand, please expand this idea.

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


> 6) Providing math functions beyond those already in C++ will not be a
> priority.
> a) GCD will be at least one exception to this.

I am not sure about this, but lets say I agree.

> 7) It should work well with other Boost libraries where possible.


> 8) Divide by zero errors for integers should be handled with an
> exception.

I do not fully like the idea of exceptions on the middle of my computations,
I prefer to set the 'state' of the object to Nan. Even for big ints.

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

I see no point in using rational numbers, but maybe I am missing something.

> 10) Drop-in algorithm replacement for various operations might be a
> nice feature.

A must if you ask me.

> Comments, suggestions, desired features? Some of the parts of this list
> are off the top of my head, so feel free to suggest changes.
> Joel Eidsath
> _______________________________________________
> Unsubscribe & other changes:

Boost list run by bdawes at, gregod at, cpdaniel at, john at