[boost] GSOC BigInt Numeric_adaptor

Subject: [boost] GSOC BigInt Numeric_adaptor
From: swagat konchada (swagatata_at_[hidden])
Date: 2010-03-31 16:08:21

> 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

> http://archive.freebsd.se/?ml=freebsd-questions&a=2007-05&m=11343770
>

>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