Boost logo

Boost :

Subject: Re: [boost] [review] Multiprecision review (June 8th - 17th, 2012)
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2012-06-16 06:19:43

Hi, here it is my review which is a summary of the discussion we have
the past week.

The scope of the library must be stated more clearly, I don't think the
library is able to manage with fixed-point arithmetic (as least as I
understand it).
The reasons why mixed arithmetic is not provided must be added in the scope.

The disadvantages to use mp_number instead of the underlying back-end
when expression templates are not used and the back-end is lightweight.
> What is your evaluation of the design?
While I was expecting a more open design/interface, I think that the
current design is good enough for some application.

* Separating the expression template and the specific number
representations (front-end/back-end) is a good design decision.

* Mixing back-ends
It is unfortunate that the front-end doesn't takes care of mixed
arithmetic yet.

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+().
I would expect the result of binary operator-() always signed.

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

I think it should be possible to mix back-ends without too much
complexity at least when expression templates are not used. When ET are
used, the ET need to take as parameters the back-end of the parameters
and the result.

If mixing independent backends (that is BE provided by 3pp) is not
desired, I think that mixing BE of the same "family" (that is provided
by the same library/developer) is a must on some domain. The backend
could contain this meta-data in some way (a typedef).

* back-end requirements

It should be clear what are the back-end requirements, which are
mandatory, which ones are used only if a specific operation of the
front-end is used and which one are used only if present as an optimization.

Each back-end should document the requirements it satisfies.

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

* Allocators and precision are orthogonal concepts and the library
should allow to associate one for fixed precision. Adding a 3rd
parameter to state if it is fixed or arbitrary precision should help in
this concern.

* Conversions

IIUC convert_to is used to emulate in c++98 compilers C++11 explicit
conversions. Could the explicit conversion operator be added on
compilers supporting it?

The front-end should make the differences between implicit and explicit

On c++11 compilers providing explicit conversion, couldn't the
convert_to function be replaced by a explicit conversion operator?

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

* Uses of bool

The use of bool in template parameters could be improved by the use of
an enum class which will be more explicit. E.g

enum class expression_template {disabled, enabled};
enum class sign {unsigned, signed};

* Default for ExpressionTemplates parameter

The ExpresionTemplate parameter could be defaulted to e.g.

ExpresionTemplate = expression_template_trait<Backend>::value

Where expression_template_trait could be defined with a defaulted value as

template<typename Backend>
struct expression_template_trait {
   static const expression_template value =

Another defaulted value could also be possible, as disabled(or enabled) by

template<typename Backend>
struct expression_template_trait {
   static const expression_template value = expression_template::disabled;

But I think a default expressed by the backend is a better default.

* noexcep:

The library interface should use the noexcept (BOOST_NOEXCEPT, ...)

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

* 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
will produce a nonnegativefixed point constant with a range and
resolution just sufficient to hold the value 2884*2^-4.

Adding a move constructor from the backend maybe could help.

constexpr mp_number<BE>::mp_number(const BE&&);

> What is your evaluation of the implementation?
The performances of mp_number<a_trivial_adaptor<float>, false>respect to
float and mp_number<a_trivial_adaptor<int>, false> and int should be
given to show the cost of using the generic interface.

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

> What is your evaluation of the documentation?

The documentation is quite good, but there are some issues that need to
be taken in account, in particular:

* The documentation should contain Throws specification on the mp_number
and backend requirements operations.

* The tutorial should add more examples concerning implicit or explicit

* The reference should state clearly which kind of rounding is done
while converting between types.

* The reference should contain the type of
boost::multiprecision::number_category<B>::type for all the provided
and why not add also B::signed_types, B::unsigned_types, B::float_types,

* The reference section must contain the relation between files and what
is provided by them.

* The documentation must explain how move semantics helps in this domain
and what the backend needs to do to profit from this optimization.

* The rounding applied when converting must be documented.

* deviations from builtin behavior: The library say that the behavior
follows as far as possible the behavior of builtin type. The
documentation should state clearly (maybe in a specific section) the
specific differences.

> What is your evaluation of the potential usefulness of the library?
This library provides a uniform interface for multiprecission number 3pp
libraries adding some optimization using expression templates, which is
in its own quite useful.
> Did you try to use the library? With what compiler? Did you have
> any problems?
I tried it with some compilers and found just some errors with
clang-2.9. Note that the errors are not present with clang-3.0.
> How much effort did you put into your evaluation? A glance? A
> quick reading? In-depth study?
An in depth study of the interface to report what is missing to use it
for my fixed-point library. I have not really take a look at the
> Are you knowledgeable about the problem domain?
I don't know too much about floating points. For the time been, I'm only
interested in fixed point types.
> And, most importantly, please explicitly answer the following question:
> Do you think the library should be accepted as a Boost library?
Even if the current state of the library don't allows me to use it for
my fixed point library I guess that the authors will add the needed
features before I could provide similar features myself.
Anyway, the library provides enough features that are missing in Boost,
so YES, this library should be accepted.

- afficher le texte cité -
By order of priority:

First all the documentation issues:

* Document the size requirements of fixed precision ints.

Yes. This should be in the documentation before release. A fixed
precision integer backend reducing the size to the maximum will be welcome.

* Be a bit clearer on the effects of sign-magnitude representation of
cpp_int - min == -max etc.


* Document cpp_dec_float precision, rounding, and exponent size.

Yes. this will be of course welcome.

* Can we be clearer in the docs that mixed arithmetic doesn't work?

I will add this even on the scope. And I think this is a must feature
for future versions of the library.

* Document round functions behaviour better (they behave as in C99).


* Document limits on size of cpp_dec_float.

Next some not too difficult features:

* Can we differentiate between explicit and implicit conversions in the
mp_number constructor (may need some new type traits)?

This is a must have, as the backend could have different expectations.

* Make fixed precision orthogonal to Allocator type in cpp_int. Possible
solution - add an additional MaxBits template argument that defaults to
0 (meaning keep going till no more space/memory).

Yes, this should be taken in account.

* Can the non-expression template operators be further optimised with
rvalue reference support?

I think this must be analyzed.

* Can any functions - in particular value initialization - be made

Unfortunately I think that the generic mp_number class can not take care
of this completely, but it should where possible.

I don't know enough the domain to have an opinion on the following:
* Add support for fused multiply add (and subtract). GMP mpz_t could use
* Document std lib function accuracy.
* Make the exponent type for cpp_dec_float a templare parameter, maybe
include support for big-integer exponents. Open question - what should
be the default - int32_t or int64_t?
* Can ring types (exact floating point types) be supported? The answer
should be yes, but someone needs to write it.
* Should there be a choice of rounding mode (probably MPFR specific)?

Good luck,

Boost list run by bdawes at, gregod at, cpdaniel at, john at