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
> and vice versa.
Conversions are supported:
> 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).
> 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).
> 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
> 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.