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-03 07:22:17

>> 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/html/boost_multiprecision/tut/conversions.html

> 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.