Re: [boost] [Review Request] Multiprecision Arithmetic Library

Subject: Re: [boost] [Review Request] Multiprecision Arithmetic Library
From: John Maddock (boost.regex_at_[hidden])
Date: 2012-04-02 05:10:24

> Nice work! It is a great first step for Boost on having its own
> multiprecision library.
>
> * libtommath
>
> Is this library really required? From your benchmarks I see that cpp_int
> type you've implemented is much better on almost all tests.

You need to read the notes and caveats - libtommath performance on *Linux 
x64* is on a par with cpp_int (as it should be really).

So it may be of use if:

* You need something more mature than the Boost code.
* You're working with very big numbers, when libtommath's more advanced 
multiplation routines may come into their own.

> * Support for Integer, Rational and Floating Point types.
>
> Are integer and floating-point types interconnected within the library?
> Wouldn't it be better to come up with two separate libraries?

Interconnected in the sense that they use the same front end code.  If the 
library was to be split it would have to be in three:

* The front end (unusable by end users just wanting a big number type).
* The integer backends.
* The floating point backends.

Personally I'd rather have a single coherent library, I think ultimately 
that's easier for end users to understand (once you've used one type from 
the library, the others all behave in the same way).

> cpp_int is an all C++ Boost licensed backend, supports both arbitrary
>> precision types (with Allocator support), and signed and unsigned fixed
>> precision types (with no memory allocation).
>
> I would like to clarify following question (didn't notice this in docs).
> Let's say I want to create cpp_int fixed type to handle 129 bit signed
> integer (1 bit for a sign and 128 to represent the value itself). Am I 
> fine
> with cpp_int_backend<128, true, void>?

Yes, it's sign magnitude representation.

>What is the size of cpp_int_backend<
> 128, true, void> structure?

Implemenation detail ;-)

In practice there's always one extra limb compared to the number you would 
expect (even for unsigned types), so the actual size depends on the size of 
the limbs, which in turn varies by platform.

So it's:

sizeof(limb_type) * (1 + (bits_requested / bits_per_limb) + (bits_requested 
% bits_per_limb ? 1 : 0))

If you really really want to know!

>Does the unary minus operator overflows for the
> smallest possible fixed integer value?

No.   std::numeric_limits would tell you that as well, as max() == -min()

> All the floating point types, have full std lib support (cos sin exp, pow
>> etc), as well as full interoperability with Boost.Math.
>
> What is the precision of the following operations: *, /, +, -, sqrt
> for the cpp_dec_float
> type?

Good question, we don't really guarentee any at present.  In practice 
they're *usually* accurate to 1eps, but they're not intended to compete with 
MPFR's guarentees.  But Chris would know more?

>What is the memory usage?

cpp_dec_float doesn't allocate any memory - everything is stored within the 
class - so it's best suited to small-medium digit counts.

>Any limitations on the maximum/minimum
> value of exponent?

Must fit in a long long.  That still gives some pretty big numbers ;-)

Just thinking out loud... is there ever any use case for big-integer 
exponents?

HTH, John.