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
> 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
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
> 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
> 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
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 acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk