swagat konchada wrote:
If we consider performance issues based on design, planning the BigInt architecture could be designed in two ways
1. 3 layers to allow optional binding to Boost's own bigint, GMP, or anyother bigint library, for the user during compile time.
2. 2 layers if we plan to limit Boost.Bigint's options to only itself and GMP.
[snip]
IMO you should look at the discussion on a numeric_adaptor by Barend Gehrels and some draft code mentioned in
to get some idea of the problem and a plausible framework which might include 'BoostsOwnBigInt' as an alternative to GMP etc.
Paul
PS But you should also be aware that another xInt project is being discussed on this group.
I checked out the numeric_adaptor scheme. It has used the GMP library and the CLN library's API to optionally provide some basic arithmetic operators on arbitrary precision decimal numbers(it was surprising since i expected adaptation for integer operations first, though i realise that there'd be no much change in the code). The main idea of the numeric_adaptor scheme though is the to_traits struct, which would cast the library dependent types to Boost's types by using explicit templates(i hope this is the right term). In fact the scheme paves the way for a direct start of the implementation of Bigint since it provided the core design(the very expression template system which was called for) of an optional BigInt library. Making this expression template system exhaustive and make it work with any one of the libraries(GMP ofcourse), must be our priority. @Paul. A. Bristow : I am also following the discussion on Xint, and would comment on it asap. Suggestions and criticism please! -- Problem is a phenomenon indicating lack of thought. Swagat Konchada