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).
My point is that big integer and floating-point types are kind of two separate concepts.
I think that's where we disagree somewhat, as I believe there is also enormous overlap (in the way that arithmetic is handled).
They have different application areas and use different external interfaces (e.g. there is no point to define cos function for big integer class or modulus operator for floating-point type).
True, in this library non-member functions that are number-kind specific (like cos and sin etc) are protected by enable_if so they can only be called with numbers of the correct "kind".
Also if the community decides that it should be a single library I would suggest that library should include type converters from integer to floating-point types and vice versa.
Conversions are supported: http://svn.boost.org/svn/boost/sandbox/big_number/libs/multiprecision/doc/ht...
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!
Well, that's what I expected and I don't think that there is anything bad in this. However user should be aware that fixed integer of 31 bits has 8 bytes size (if sizeof(limb_type) = 4).
Nod.
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?
This is an important point, so would be good at least to mention it in the docs. I'd like also to see more details on this type in the docs (e.g. examples, areas of application).
Nod.
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?
Yes, those are very large numbers :-). I would say that int32 exponent should be good enough (I don't mean that it should be used). I am eager to see applications of int64 exponent range.
Thanks for the comments, John.