Subject: Re: [boost] [Review Request] Multiprecision Arithmetic Library
From: Andrii Sydorchuk (sydorchuk.andriy_at_[hidden])
Date: 2012-04-02 18:29:26
> 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. 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). 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.
> 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.
Unsubscribe & other changes: http://lists.boost.org/**
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk