Hi, "Joel Eidsath" <jeidsath@gmail.com> wrote in message news:4318989B.7000503@gmail.com...
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 that.
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.
Agree.
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.
Agree.
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.
Agree.
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: http://lists.boost.org/mailman/listinfo.cgi/boost