Here are my comments from reading through the tutorial.
Many thanks for the detailed comments.
* "It's also possible to access the underlying mpz_t via the data() member function of gmp_int" I'm assuming from this that mpz_int ends up inheriting data() from gmp_int? Otherwise, this wouldn't be terribly useful. Anyway, (I had a similar comment for cpp_int) I thing you should either specify everything in terms of the appropriate specializations of mp_number or say somewhere early on that mp_number inherits all the behavior of the backend. Wait... I see v.backend().data() in the example.
Right, the backend type is accessible via the backend() member function.
* "it is a rather strange beast as it's a signed type that is not a 2's complement type" isn't this true of GMP and cpp_int as well? Why the special warning for tom_int?
Lib tommath's bitwise operations behave differently from a 2's complement type. In contrast gmp and cpp_int "simulate" 2's complement behaviour when performing bitwise ops on negative numbers. Note that this is an area where the behaviour of builtin types is undefined in the std anyway, there is however, a general expection that they will actually behave in a certain way.
* "... just set the n'th bit in the ..." Oh, come on. I'm sure there's a way to use a proper superscript.
I'm not sure I follow, do you mean make mp_number subscriptable to access the individual bits? Obviously that's possible to do, I'd be interested in others thoughts as to whether it's the correct interface choice.
* On a related note, what does "standard library support" mean? ... In the example, I see "log(b)." I think this terminology is imprecise. log(b) does not call a standard library function at all.
I'll try and be more specific - it means that all the functions (from cmath) and traits (numeric_limits) that operate on builtin floating point types, are also defined for these types.
* "Narrowing conversions are truncating." This is unfortunate. I'd prefer it to round according to the current rounding mode.
Chris will have to answer that one.
Defining a Lambda Function:
* The name of the section is misleading because "Lambda" has a totally different meaning in programming. Maybe find a different example.
Point taken, shame, it made a nice simple example :-(
* I'm a little concerned that if the arguments of the final version, JEL5 are expression templates, they would be evaluated multiple times. Is this the case?
My bad, yes that would be the case. Will fix the example.
* "An mp_number can be converted to any built in type, via the convert_to member function" In C++11, can we use an explicit conversion operator?
Not yet, but's already ben asked for and trivial to add.
Generating Random Numbers:
* boost/multiprecision/random.hpp should go away. I'll try to work out the changes needed to make Boost.Random work directly.
I hoped you'd say that ;-) However, I've deliberately held off submitting patches or suggesting any changes until/unless the interface on this library is accepted. No point in chasing a moving target. Just consider the code in random.hpp proof of concept for now, I figure folks would complain about it not working if I didn't provide it. Regards, John.