[boost] [Review Request] Multiprecision Arithmetic Library
John Maddock
I'd like to ask for a formal review of the Multiprecision Arithmetic
Library, currently in the sandbox.
Features:
* Expression template enabled front end.
* Support for Integer, Rational and Floating Point types.
Supported Integer backends:
* GMP.
* Libtommath.
* cpp_int.
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).
There are also some integer specific functions - for Miller Rabin testing,
bit fiddling, random numbers. Plus interoperability with Boost.Rational
(though that loses the expression template frontend).
Supported Rational Backends:
* GMP
* libtommath
* cpp_int (as above)
Supported Floating point backends:
* GMP
* MPFR
* cpp_dec_float
cpp_dec_float is an all C++ Boost licensed type, adapted from Christopher
Kormanyos' e_float code (published in TOMS last year).
All the floating point types, have full std lib support (cos sin exp, pow
etc), as well as full interoperability with Boost.Math.
There's nothing in principal to prevent extension to complex numbers and
interval arithmetic types (plus any other number types I've forgotten!), but
I've run out of energy for now ;-)
Code is in the sandbox under /big_number/.
Docs can be viewed online here:
http://svn.boost.org/svn/boost/sandbox/big_number/libs/multiprecision/doc/html/index.html
And of course, I'm looking for a review manager ;-)
Many thanks, John.
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Daniel Trebbien
That is some impressive-looking work, especially the Performance
Comparison pages.
I have briefly looked through the documentation and have a few
questions/comments:
1. Is there a fairly complete example program that uses
Boost.Multiprecision? I saw the Miller-Rabin test program, which is
good. Perhaps a few more examples will help users to understand the
basics of working with the library.
2. Do the round functions of mp_number (round, iround, lround,
llround) behave like the POSIX round functions in that they always
round away from zero? That might be good to document.
3. Does Boost.Multiprecision support a choice of rounding mode?
Overall, the API looks sensible and complete. Excellent work!
Daniel Trebbien
Vicente J. Botet Escriba
> Folks,
>
> I'd like to ask for a formal review of the Multiprecision Arithmetic
> Library, currently in the sandbox.
>
> Features:
>
> * Expression template enabled front end.
> * Support for Integer, Rational and Floating Point types.
>
very good work.
> Supported Integer backends:
>
> * GMP.
> * Libtommath.
> * cpp_int.
>
> 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'm wondering if the following compiles and what is the type of c
mp_uint128_t a;
mp_uint256_t b;
auto c = a + b;
From the documentation I have the impression that we can not mix back-ends.
It seems to me that fixed precision and allocation are orthogonal
features. Why the fixed precision types can not use an allocator?
>
>
> There's nothing in principal to prevent extension to complex numbers
> and interval arithmetic types (plus any other number types I've
> forgotten!), but I've run out of energy for now ;-)
I'm working on a fixed_point library (see the sandbox code, sorry, but
there is no doc yet but
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3352.html is
quite close ).
I would like to see if your front-end could also improve the
performances in this case. I will try to adapt it to the back-end
constraints soon.
> And of course, I'm looking for a review manager ;-)
>
Good luck,
Vicente
Andrii Sydorchuk
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.
* 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?
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>? What is the size of cpp_int_backend<
128, true, void> structure? Does the unary minus operator overflows for the
smallest possible fixed integer value?
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? What is the memory usage? Any limitations on the maximum/minimum
value of exponent?
Thanks,
Andrii Sydorchuk
Unsubscribe & other changes: http://lists.boost.org/**
mailman/listinfo.cgi/boost<http://lists.boost.org/mailman/listinfo.cgi/boost>
Paul A. Bristow
> From: boost-...@lists.boost.org [mailto:boost-...@lists.boost.org] On Behalf Of Daniel
> Trebbien
> Sent: Sunday, April 01, 2012 6:30 PM
> To: John Maddock
> Cc: bo...@lists.boost.org
> Subject: Re: [boost] [Review Request] Multiprecision Arithmetic Library
>
> That is some impressive-looking work, especially the Performance Comparison pages.
>
> I have briefly looked through the documentation and have a few
> questions/comments:
>
> 1. Is there a fairly complete example program that uses Boost.Multiprecision? I saw the
Miller-Rabin test
> program, which is good. Perhaps a few more examples will help users to understand the basics of
working
> with the library.
I'm impressed by this - both Chris's and John's work.
It proves my thesis that no Maddock program is complete without lots of templates and some MPL as
condiment!
Boost has needed this for a long time, both integer and real.
And now we have both.
To be able to use the GMP and other packages optionally is a big bonus.
I've also said that we must have more examples.
This is going to be used by the 'great unwashed' when they run out of bits on the built-in types.
So they won't read the manual (probably even if all else fails!) and will rely on examples to get
they going, and to help out when they fall into some of the pits awaiting the unwary user (I fell
:-( ).
Suggestions for examples?
Paul
---
Paul A. Bristow,
Prizet Farmhouse, Kendal LA8 8AB UK
+44 1539 561830 07714330204
pbri...@hetp.u-net.com
John Maddock
>
>mp_uint128_t a;
>mp_uint256_t b;
>auto c = a + b;
>
> From the documentation I have the impression that we can not mix
> back-ends.
Correct, it's a compiler error.
Allowing mixed type arithmetic opens up a whole can of worms it seems to me,
plus I don't even want to think about how complex the operator overloads
would have to be to support that!
So for now, if you want to conduct mixed arithmetic, you must explicitly
cast one of the types.
>It seems to me that fixed precision and allocation are orthogonal features.
>Why the fixed precision types can not use an allocator?
Good question. It seemed to me that the most common use case for fixed
precision types was for types "just a bit wider than long long", where it
was important not to be allocating memory. Plus if you're going to allow
memory allocation, wouldn't it be safer to use the arbitary precision type
and avoid the risk of overflow altergether?
>I'm working on a fixed_point library (see the sandbox code, sorry, but
>there is no doc yet but
>http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3352.html is quite
>close ).
That paper is interesting, particularly in it's allowance of mixed-mode
arithmetic.
>I would like to see if your front-end could also improve the performances
>in this case. I will try to adapt it to the back-end constraints soon.
Unless your number types perform memory allocation, the chances are that
expression templates may well not be an optimization (or even a slight
dis-optimization). Even when memory allocation is performed and temporaries
are expensive to construct, subjectively, the big performance gains only
really happen when the system is under load - makes sense when you think
about it - not sure how to go about quantifying that though :-(
BTW, it's not documented, and may be slightly out of date now, but there's a
trivial adapter template in boost/multiprecision/arithmetic_backend.hpp that
allows any type with the usual arithmetic operators to be used with the
expression template front end, so use would be:
mp_number<arithmetic_backend<YourType> >
It certainly won't give you optimized performance, but it may give you a
quick and dirty idea as to whether writing a proper backend is worthwhile.
HTH, John.
John Maddock
> 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.
Beman Dawes
> Folks,
>
> I'd like to ask for a formal review of the Multiprecision Arithmetic
> Library, currently in the sandbox.
>
>
> And of course, I'm looking for a review manager ;-)
This seems to me to be a particularly timely library for Boost, and
perhaps the C++ standard library. Thus I'd like to encourage someone
to volunteer as review manager, and get the review process started as
soon as possible.
--Beman
Christopher Kormanyos
> I'm impressed by this - both Chris's and John's work.
Thank you. There's still a long way to go in terms of digits,
but it's *definitely* a good start.
<snip>
> Boost has needed this for a long time, both integer and real.
> And now we have both.
> To be able to use the GMP and other packages optionally is a big bonus.
Yeah, for *real*!
<snip>
> Suggestions for examples?
Well, I did work out 8 examples for the original publication
in the ACM. We could adapt some of these for big_number
to lend a more example-oriented quick start to the hands-on user.
Best regards, Chris.
Christopher Kormanyos
>> 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 guarantee any at present.
> In practice they're *usually* accurate to 1eps,
> but they're not intended to compete with MPFR's guarantees.
> But Chris would know more?
My basic operations (add, sub, mul, div) are on-par or faster
for a variety of reasons. For example, I don't allocate---just use
std::array "on the stack".
Those GMP and MPFR guys can not program in a professionally
adherent fashion. But they sure do have efficient algorithms!
Their square root, exponential, logarithmic and trigonometric
functions beat mine hands down. I'd like to get a hold of their
algorithms and program them in a readable, portable fashion.
I think they use, for example, binary splitting for trigonometric functions,
whereas I use Taylor.
>> Any limitations on the maximum/minimum value of exponent?
> Must fit in a long long. That still gives some pretty big numbers ;-)
In other words, approx. 10^(10^19) for 64-bit long long.
The Python language MP stuff has unlimited exponents.
I forgot what that thing is called, but it's another cool tool.
Best regards, Chris.
Vicente J. Botet Escriba
>> I'm wondering if the following compiles and what is the type of c
>>
>> mp_uint128_t a;
>> mp_uint256_t b;
>> auto c = a + b;
>>
>> From the documentation I have the impression that we can not mix
>> back-ends.
>
> Correct, it's a compiler error.
>
> Allowing mixed type arithmetic opens up a whole can of worms it seems
> to me, plus I don't even want to think about how complex the operator
> overloads would have to be to support that!
>
> So for now, if you want to conduct mixed arithmetic, you must
> explicitly cast one of the types.
arithmetic. The type of a fixed_point operation depends on the
quantization of its arguments.
With fixed_point arithmetic the type of fixed_point<7,0> +
fixed_point<8,0> is fixed_point<9,0>. Note that no overflow is needed as
the resulting type has enough range.
Another example
fixed_point<10,2> a;
fixed_point<2,3> b;
fixed_point<2,2> c;
auto d = (a + b) * c;
The type of d should be something like fixed_ponit<13,5>. If the
pixed_point operation works only with parameters with the same range and
resolution the overflow problem appears on temporaries.
Using cast the expression result in something unreadable
auto d = (fixed_ponit<13,5>(a) + fixed_ponit<13,5>(b)) *
fixed_ponit<13,5>(c);
Overflow and rounding is needed only when you assign types with
different quantizations. For example
fixed_point<12, 4> d = (a + b) * c;
will need to round from 5 to 4 resolution bits and to reduce the scale
from 13 to 12.
>
>
>> It seems to me that fixed precision and allocation are orthogonal
>> features. Why the fixed precision types can not use an allocator?
>
> Good question. It seemed to me that the most common use case for
> fixed precision types was for types "just a bit wider than long long",
> where it was important not to be allocating memory. Plus if you're
> going to allow memory allocation, wouldn't it be safer to use the
> arbitary precision type and avoid the risk of overflow altergether?
Knowing the range and resolution (i.e. precision) at compile time is a
must in some domains. In the context I could use this, I will not use
the allocator as the size stay reasonale, but for me the interface
should let the choice to the user.
>
>
>> I'm working on a fixed_point library (see the sandbox code, sorry,
>> but there is no doc yet but
>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3352.html is
>> quite close ).
>
> That paper is interesting, particularly in it's allowance of
> mixed-mode arithmetic.
>
>> I would like to see if your front-end could also improve the
>> performances in this case. I will try to adapt it to the back-end
>> constraints soon.
>
> Unless your number types perform memory allocation, the chances are
> that expression templates may well not be an optimization (or even a
> slight dis-optimization). Even when memory allocation is performed
> and temporaries are expensive to construct, subjectively, the big
> performance gains only really happen when the system is under load -
> makes sense when you think about it - not sure how to go about
> quantifying that though :-(
are you saying that the front_end is not useful for cpp_int when no
allocator is used?
Note also that some processors could offer intrinsics for (a + b) * c.
But this may be out of the scope of your library.
> BTW, it's not documented, and may be slightly out of date now, but
> there's a trivial adapter template in
> boost/multiprecision/arithmetic_backend.hpp that allows any type with
> the usual arithmetic operators to be used with the expression template
> front end, so use would be:
>
> mp_number<arithmetic_backend<YourType> >
>
> It certainly won't give you optimized performance, but it may give you
> a quick and dirty idea as to whether writing a proper backend is
> worthwhile.
>
>
I'll think a little bit more on how and if expression templates could
improve the performances of fixed_point arithmetic that don't use memory
allocation.
I'll study your expression templates work to see if adapting it to mixed
range+resolution could be an option.
Best,
Vicente
Ronald Garcia
I have received your request and will add it to the review schedule.
Best,
Ron
Andrii Sydorchuk
> 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.
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
> 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.
Andrii
Unsubscribe & other changes: http://lists.boost.org/**
mailman/listinfo.cgi/boost<http://lists.boost.org/mailman/listinfo.cgi/boost>
Topher Cooper
> 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.
>
> Andrii
>
universe -- the physically observable universe) in Plank units (the
smallest physically meaningful length according to QM) is about
1.5*2^204, so 9 bits (positive and negative exponents) is all that is
required to express the exponent for any physical distance in any
physically meaningful units. Volumes would reach binary exponent of 613
so 11 bits covers this with generous room to spare. I doubt you will
find any physical quantities that will be much larger. Combinatorics
can easily generate very large quantities, of course, but if you are
getting into those ranges you probably will be using logarithms. So 16
bits is probably as much as you can reasonably expect to need (lots of
bits in the mantissa is, of course, justifiable to preserve precision in
intermediate results), and 32 would be as much as you can *un*reasonably
expect to need -- and more.
I'm not actually arguing against the choice of int64 representation for
the exponents either. There are other issues then utility in efficient
design and a few unused bits are worth it for performance or even just
code simplicity. Just thought I would put things in perspective. (I'm
partially responding with amusment here, because I remember when we
wondered whether there really was any point to the 15 bit exponents when
the HFloat (H = Huge) format was introduced the the VAX architecture on
request/recommendation of some members of the scientific community, the
GFloat format (G=Grand) introduced at the same time for the same reason
had 11 bit exponents).
Topher
Christof Donat
> > 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.
Mathematics has some need to work with really very big numbers. That is
whenever you try to disprove a hypothesis like e.g. the Rieman hypothesis by
experimentally searching for a case where it does not hold.
That is nothing I am doing, but it to my mind when I thought about where to
use exponents bigger than int32.
Is there any reason not to make the exponent type a template parameter so that
the user can chose arbittrarily instead of trying to anticipate future uses of
the library?
Christof
--
okunah gmbh Software nach Maß
Werner-Haas-Str. 8 www.okunah.de
86153 Augsburg c...@okunah.de
Registergericht Augsburg
Geschäftsführer Augsburg HRB 21896
Christof Donat UStID: DE 248 815 055
Thomas Heller
>
> Hi,
>
> > > 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.
>
> Mathematics has some need to work with really very big numbers. That is
> whenever you try to disprove a hypothesis like e.g. the Rieman hypothesis by
> experimentally searching for a case where it does not hold.
>
> That is nothing I am doing, but it to my mind when I thought about where to
> use exponents bigger than int32.
>
> Is there any reason not to make the exponent type a template parameter so that
> the user can chose arbittrarily instead of trying to anticipate future uses of
> the library?
Just a crazy idea ... what about if the exponent is a big integer as
well? And the mantissa ... guess you can go all crazy, hope this is
supported by the library!
> Christof
Andrii Sydorchuk
> Just a crazy idea ... what about if the exponent is a big integer as
> well? And the mantissa ... guess you can go all crazy, hope this is
> supported by the library!
My main point against this idea would be that this might drop performance a
lot.
As far as I know GMP library also uses 64 bit exponent for floating-point
types.
Is there any reason not to make the exponent type a template parameter so
> that
> the user can chose arbittrarily instead of trying to anticipate future
> uses of
> the library?
I would suggest this to be a good solution. At least support of int32 and
int64 via template parameter would be vital.
Yeah -- the diameter of the observable universe (not the observed universe
> -- the physically observable universe) in Plank units (the smallest
> physically meaningful length according to QM) is about 1.5*2^204, so 9 bits
> (positive and negative exponents) is all that is required to express the
> exponent for any physical distance in any physically meaningful units.
I have some experience with implementing multiprecision geometric
predicates.
At some point I needed to cast 2048 bit big integer to 64 bit double and
the problem is
that double is not capable to handle it. This is so far the only issue I
encountered with
limitation of 11 bits exponent. Also we might consider the fact that
IEEE754 architecture for
128 bit double has 15 bit exponent the same as for the 80 bit double.
Andrii
Neal Becker
I have implemented my own fixed_point, and I debated whether the result of
operations should automatically be a wider type. In the end, I decided it was
best to use explicit casting. Explicit is better than implicit. It's a bit
more verbose, but I can live with that.
Would you advocate that in C++, int8 * int8 -> int16??
John Maddock
>> 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.
John Maddock
>that
>the user can chose arbittrarily instead of trying to anticipate future uses
>of
>the library?
Probably not actually a bad idea, or hard to do, other than upping testing
times yet more....
John.
John Maddock
> well? And the mantissa ... guess you can go all crazy, hope this is
> supported by the library!
Not yet, but not impossible (other than it messing up
std::numeric_limits<>::max_exponent). Of course making the mantissa
arbitrary precision is definitely not possible - unless you can tell me how
exactly many digits Pi has ;-)
John.
Jeffrey Lee Hellrung, Jr.
> Just a crazy idea ... what about if the exponent is a big integer as
>> well? And the mantissa ... guess you can go all crazy, hope this is
>> supported by the library!
>>
>
> Not yet, but not impossible (other than it messing up
> std::numeric_limits<>::max_exponent). Of course making the mantissa
> arbitrary precision is definitely not possible - unless you can tell me how
> exactly many digits Pi has ;-)
>
Well I'd imagine that maybe you could evaluate the precision of, e.g., pi
on-demand and lazily. I would consider that a form of arbitrary precision.
I'd also imagine such a technique outside the (present) scope of this
library.
- Jeff
Jeffrey Lee Hellrung, Jr.
> Docs can be viewed online here: http://svn.boost.org/svn/**
> boost/sandbox/big_number/libs/**multiprecision/doc/html/index.**html<http://svn.boost.org/svn/boost/sandbox/big_number/libs/multiprecision/doc/html/index.html>
>
> And of course, I'm looking for a review manager ;-)
>
> Many thanks, John.
I will have to take a look at it this week, sounds great!
My initial question/request pertains to putting this library within the
context of past attempts at getting an extended precision arithmetic
library into Boost. I'm specifically thinking of Chad Nelson's XInt library
reviewed approximately a year ago [1]. I'm wondering what, if any,
influence the XInt library and the XInt review process/result had on your
design decisions for MAL. I also hope that if issues similar to those
brought up during the XInt review also apply to MAL that you'll be prepared
to address them.
That said, I'm pretty confident you've done your homework :)
- Jeff
[1] http://lists.boost.org/boost-announce/2011/04/0305.php
John Maddock
>
> My initial question/request pertains to putting this library within the
> context of past attempts at getting an extended precision arithmetic
> library into Boost. I'm specifically thinking of Chad Nelson's XInt
> library
> reviewed approximately a year ago [1]. I'm wondering what, if any,
> influence the XInt library and the XInt review process/result had on your
> design decisions for MAL. I also hope that if issues similar to those
> brought up during the XInt review also apply to MAL that you'll be
> prepared
> to address them.
>
> That said, I'm pretty confident you've done your homework :)
Nod. I looked back over the review comments, the main things I spotted
were:
* No expression template support.
* Only a GMP backend.
* No support for fixed precision ints.
Those I hope are fixed in this library, if I missed anything else, then no
doubt I'll soon find out!
Regards, John.
Vicente J. Botet Escriba
I can not change C/C++. But why not do it for user defined types as a
fixed point class? This avoids at least unexpected overflows while been
efficient.
Vicente
Andrii Sydorchuk
I would say that the result of the expression should not grow
automatically. Consider example of summation of 1000 int32.
The result value would have 1031 bits size, while the actual value it holds
would be at most int42.
There is also another template trick that allows resulting type to be at
least as big as each of the operands:
template <int N, int M>
big_int<(N>M?N:M)> add(const big_int<N>& a, const big_int<M>& b) {
big_int<(N>M?N:M)> result;
// Implementation follows.
return result;
}
I used this approach for my personal fixed int routines.
The main point of a fixed integer type is its performance. It allows user
to write complex math formulas without thinking about slow memory
allocations.
I would say that users are responsible to ensure that fixed int doesn't
overflow. If somebody is not satisfied with such behavior they could
use big integer types with dynamic memory allocation.
John Maddock
> in the ACM. We could adapt some of these for big_number
> to lend a more example-oriented quick start to the hands-on user.
Good thinking - I just pinched example 3, and reworked it here:
http://svn.boost.org/svn/boost/sandbox/big_number/libs/multiprecision/doc/html/boost_multiprecision/tut/floats/jel.html
John.
Christopher Kormanyos
> I'd like to ask for a formal review of the Multiprecision Arithmetic Library, currently in the sandbox.
<snip>
> cpp_dec_float is an all C++ Boost licensed type, adapted from Christopher Kormanyos' e_float code (published in TOMS last year).
Great work, John!
And let's not forget to mention in the documentation
that the cpp_dec_float back-end (in the present implementation)
is limited to < 500 (need to check) decimal digits of precision.
Best regards, Chris.