Re: [boost] Interest in an arbitrary precision library?

From: Lucas Galfaso (lgalfaso_at_[hidden])
Date: 2005-09-02 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 drop-in
> replacements for the built-in 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 hand-coded 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)  Drop-in 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
>