
Boost : 
From: Lucas Galfaso (lgalfaso_at_[hidden])
Date: 20050902 18:49:54
Hi,
"Joel Eidsath" <jeidsath_at_[hidden]> wrote in message
news:4318989B.7000503_at_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 dropin
> replacements for the builtin 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 handcoded 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) Dropin 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
>
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk