* the example about using 0 vs 11 temporaries doesn't mention what happens to the boost package if we disable expression template. Does it use a single temporary (using rvalue-references) or plenty?
Plenty, haven't measured how many, but I'd expect it to be the same as for mpclass. I guess I should cover that.
I think you really want to investigate using rvalue references, in that case. Which reminds me: there is some overlap with boost/operators.hpp (I heard someone was rewriting it?), so the rvalue reference techniques could be the same, and the documentation could say something about the relation between the 2.
rvalue references and move semantics are already supported.
* you could get good results with a backend that uses gmp's mpn_* functions but not the mpz_t type.
Maybe, but I'm not sure what that gains us other than memory allocation control?
It seems to me that we would basically be re-inventing the mpz_* gmp functions, which seems like a bad idea.
For large numbers, the cost of operations dominates, and gmp is hard to beat. For small numbers, allocation dominates the cost. mpz_t is quite bad there as it always allocates. Even default and move constructors can't be efficient with mpz_t for that reason.
Nod. However, I think someone already familiar with gmp's internals should write that backend if it's to be done - otherwise it looks like a recepe for introducing bugs :-(
Things like your mixed backend (fixed allocation for small sizes and dynamic for larger sizes) are very interesting. I am also wondering about the possibility to use a different type for temporaries. As much as possible, you'd want to avoid allocation for temporaries, using fixed arrays or even alloca/VLA where available. But that doesn't mean your number type itself should contain an array. gmp's addmul function (kind of like FMA) should be useless, but it is actually interesting because it bypasses the allocation for the intermediate result, which makes it fast.
So there is quite a bit of potential there. But that's just a suggestion, it doesn't have to be done now, or by you.
Nod. Support for fused multiply-add is on my TODO list.
In fact, I believe that Boost.Math already set the bar on this one because when using Boost.Math with an extended precision type (this is possible), all implicit conversions to/from the built-in types are supported.
I believe it would be incorrect to treat interaction with built-in types behave one way in Boost.Math and a different way in a potential Boost.Multiprecision.
Isn't Boost.Math about floating point (I haven't used it so I don't know)? It makes sense to allow conversions from double to bigfloat but not from double to bigint...
That would be my opinion too: double to big-float is safe desirable and OK. built in integer to big integer is safe desirable and OK. double to built in integer is not so good, and should probably be explicit. Regards, John.