Re: [boost] [review] Multiprecision review (June 8th - 17th, 2012)

Subject: Re: [boost] [review] Multiprecision review (June 8th - 17th, 2012)
From: John Maddock (boost.regex_at_[hidden])
Date: 2012-06-17 04:36:43

Vicente,

Many thanks for the review, some specific comment follow...

>I would expect the result of unary operator-() always signed. This 
>operation is not defined in the front end as it isn't unary operator+().

The operators are defined as non-members.

>I would expect the result of binary operator-() always signed.

That's probably possible, although it makes the behaviour noticably 
different from builtin integers.

>Adding mp_uint128_t and mp_int128_t and assign it to a mp_int256_t needs 
>two explicit conversions. This interface limits some possible 
>optimizations.

I'll do what I can do in this area, but the code is already pretty complex 
and I worry about it becoming untestable, as well as the issues in deciding 
what the "right thing to do" is for mixed arithmetic.

>* I would expect the library provide a back-end for representing N-bits 
>integers with exactly (N/8)+1 bytes or something like that.
>
>* And also an overflow aware back-end for fixed precision integers.

OK, I'll see what I can do.

>* shift operations
>
>An overload of the shift operations with a unsigned should be provided (in 
>addition of the signed one) in order to avoid the sign check.

It's there already - the backend is always fed an unsigned value, and 
mp_number only range checks the value provided if it's signed.

>* noexcep:
>
>The library interface should use the noexcept (BOOST_NOEXCEPT, ...) 
>facilities.

There are some interfaces where that's trivial (for example the operator 
overloads returning an expression template).  For mp_number's member 
functions, I don't know enough about noexcept in non trivial situations to 
know if it's possible (can a template member function be noexcept when 
whether it throws or not, depends on a dependant type?)   There are also 
plenty of functions which should be noexcept as they only call external C 
library functions, but probably can't be marked as such without modifying 
third party headers (gmp.h for example).

>* constexpr:
>
>It is unfortunate that the generic mp_number front end can not make use
contexpr as not all the backends can ensure this.
>It will be worth however seen how far we can go.

I think the functions that return an expression template can be constexp. 
Will investigate other uses.

>* literals
>
>The library doesn't provide some kind of literals. I think that the 
>mp_number class should provide a way to create literals if the backend is 
>able to. For example
>to_nonnegative<2884,-4>()|
>will produce a nonnegativefixed point constant with a range and resolution 
>just sufficient to hold the value 2884*2^-4.

Again I don't yet know enough about constexp in non-trivial use cases to 
know if we can do this.  Will investigate.

>Adding a move constructor from the backend maybe could help.
>
>constexpr mp_number<BE>::mp_number(const BE&&);

Will add.

>Boost.Move should be used to emulate move semantics in compilers don't 
>providing it.

Will investigate.

Regards, John.