Re: [boost] [review] Multiprecision review scheduled for June 8th - 17th, 2012

Subject: Re: [boost] [review] Multiprecision review scheduled for June 8th - 17th, 2012
From: John Maddock (boost.regex_at_[hidden])
Date: 2012-05-31 13:12:09

> A few quick comments:
>
> * gmpxx != mpfr_class

Quite right, will correct.

> * the version of gmpxx in the repository hasn't used any temporary for the 
> example given in the introduction for a while, it is only because of a 
> slow release cycle that you haven't seen it yet (will be in 5.1).

OK.  I guess the problem with such comparisons is they're out of date as 
soon as they're written.  I can only test what's been released though.

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

> * having an implicit narrowing conversion from double to bigint is a bad 
> idea, it should be explicit (it isn't completely obvious from the doc if 
> that is the case).

It's pretty hard to have some constructor conversions implicit and others 
explicit.  Might be possible with enable_if though.  Will investigate.

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

> * what about infinite precision floats? By that I mean something like 
> bigint*2^n, where operations + - * are computed exactly. It can be quite a 
> bit faster than rationals, when it is sufficient.

Wouldn't those get horribly large very quickly?  Off hand I know of no other 
library that implements such a beast?

> * if I want reference-counting, I guess that should be done in a back-end.

That's a touchy subject ;-)

Reference counting seems to have gone out of favor in recent years for 
"string like objects" on the grounds that it causes more issues than it 
solves, it would be interesting to know whether it helps any for say, 
Boost.Math integration, where special function arguments are by value.  My 
hunch is probably not much - purely because most operations are so dominated 
by multiply and divide times that a small number of extra copies just 
doesn't matter much (compared to say the massive number of temporaries you 
get without expression templates).

But yes, if reference counting is to be used, it has to be used by the 
backend - it's not something that should be in the frontend as for many 
types it would be a dis-optimization.

Thanks for the comments, John.