Re: [boost] Boost::Bigint header draft - suggestions are welcome!

From: Arseny Kapoulkine (arseny.kapoulkine_at_[hidden])
Date: 2007-05-07 12:38:45

Hello, boost-request.

> Date: Mon, 7 May 2007 12:00:04 -0400
> From: "Jarrad Waterloo" <jwaterloo_at_[hidden]>
> Subject: Re: [boost] Boost::Bigint header draft - suggestions are
>         welcome!

> I'll address last first. [snip] Multiple designs some
> utilize bit mask so the process can be repeated faster but I have only saw
> those on 'bigger ints'.

I see what you mean. It's added in a suggestion list, later all
suggestions will be sorted on priority and some set will be chosen
that will be a part of base functionality, and the rest will be
postponed.

> Now onto GMP big_int on the stack, I know of it but have never used it as I
> couldn't get it compiled on Windows and those with the knowledge are tight
> lipped. In any case, I thought they were a set of C functions that can work
> on int arrays whether heap or stack allocated. If that is the case why
> wouldn't it have a stack implementation!

You are right, GMP does provide a set of C functions that work on int
arrays. But GMP does more actually. Among the things that are
interesting to us GMP provides 2 layers of functionality. The first
one is extremely low-level, works only with positive integers, is hard
to use and may change in the future releases. So the current decision
is as follows:

The interface for the storage strategy IS developed, but it is used
only for the default implementation. The GMP implementation still uses
high-level GMP functions.

Adding ability to use arbitrary storage implementation for GMP is in the
suggestion list, so it will be reviewed together with the others and
done after the base part is (by the way, I expect to finish the base
functionality together with tests and documentation by the end of
July, which will leave a month for implementing features in the list).

Moving the storage implementation to the bigint_base template (thus
forcing every implementation to be able to work with custom
implementations) is a design decision which has not be made without
thoughts. For now it is thought that this decision will be made when
(if) GMP support will be implemented via a low level layer.

> On a side note: I don't know how this will go over with other boost members.
> But could this be driver based. What I mean is the default implementation is
> the standard C++ approach which would always exist but if a faster one
> exists such as GMP that that is used. Does GMP versus standard has to be a
> part of the objects type? Just a thought but the important thing is to
> finally get an infinite int library.

There always will be a strategy-based class (bigint_base for now) with
different implementations so the user can use the one he desires.

Though there is a convenience typedef bigint (and there may be more
when more implementations are developed), and this one can indeed
depend on the existing implementations (like,

#ifdef GMP_SUPPORTED

#include <boost/bigint/detail/bigint_gmp_implementation.hpp>
typedef bigint_base<bigint_gmp_implementation> bigint;

#elif SOMEOTHERLIBRARY_SUPPORTED
...
#else

#include <boost/bigint/detail/bigint_default_implementation.hpp>
typedef bigint_base<bigint_default_implementation> bigint;

#endif
). Moreover, it likely will.

By the way, I am assembling a proper suggestion list and expect to
upload it to the SVN sandbox repository in several hours, and update
it according to the input received from this mailing list and other
places.

-- 
Best regards,
 Arseny                          mailto:arseny.kapoulkine_at_[hidden]