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-02 04:53:27

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

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