Re: [boost] Google SoC 2007 Big Integer project

From: Kevin Sopp (baraclese_at_[hidden])
Date: 2007-03-24 07:31:41

> do you mean that it's possible to use std::allocator methods in order to
> grow allocated space without the need to initialize it again with old data
> ?

No, I meant that you can use the realloc() function throughout the
library without having to worry about whether the user passed in an
allocator with std::allocator interface or an allocator that supports
realloc(). By specializing a struct on the allocator type, it will act
as a proxy and you call the struct's realloc() in the library.
If the user passes in std::allocator the proxy realloc() function will
still do an alloc/copy/destroy.

> >> (4) decide if we have to use exception handling C++ constructs for
> >> arithmetic exceptions ( divide by zero, etc) or simply abort the
> >> program;
> >> this is essentially a matter of performance;
> >
> > Not just a matter of performance but also one of interface, usually
> > bigint will be used with data that comes from outside the program so
> > programmer has to be prepared to catch bigint exceptions. This could
> > be parameterized <bool use_exceptions = true/false>. A member variable
> > to hold some state about the bigint will be useful, that way you can
> > check for overflow, divide by zero and encode +inf, -inf, etc.
>
> >> (12) it would be nice to support infinity and indefinite forms, but it
> >> could mean performance problems because we'd have to evaluate all
> >> possible
> >> cases, maybe it will be better realize a specific wrapper/adaptor class
> >> for such a goal, moreover this class adaptor could be used also for
> >> standard integral type;
> >
> > I suggest as above having a state variable, I suspect checking for the
> > states gets lost in the noise especially when the numbers get large.
> >
>
> I don't know if checking for states doesn't matter compared to the
> complexity of multi precision algorithms. It's possible, I should try.
>
> parametrization for infinity, NaN and exception it's ok;
> anyway what I wanted to point out it's that in the case there is a
> performance loss, managing infinity and undefined states, then it is
> better to implement different classes and it's so even using template
> parameters: for instance classes big_integer<WITH_INF> and
> big_integer<WITHOUT_INF> ( WITH_INF = true, WITHOUT_INF = false, and I've
> omitted the other template parameters ) will exdend a common class in such
> a way to share as much as possible, but they will be two different
> template specialization of <bool use_inf>.

It sounds like this will make things more complex than necessary. I
just looked at the GMP manual [http://gmplib.org/manual/] and it looks
like they don't support infinities etc. in fact they don't handle
division by zero either because "This lets a program handle arithmetic
exceptions in these functions the same way as for normal C int
arithmetic."

Kevin