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.