Not quite a review as it's way too late :), but some comments on probably interesting experience I've got while trying out multiprecision from sandbox together with Boost.UBLAS . Both libraries are generic in the way that one can be used instead of builtin float and double, and the other should support such types.
I've found out that they don't play well together, probably due to the fact that UBLAS uses its own expression templates. A simple example of code that fails to compile is below:
------------------
#include <boost/numeric/ublas/vector.hpp> #include <boost/multiprecision/cpp_dec_float.hpp>
typedef boost::multiprecision::mp_number< boost::multiprecision::cpp_dec_float<50> , true > float_type;
int main(int argc, char* argv[]) { boost::numeric::ublas::c_vector<float_type, 3> v1,v2; inner_prod( v1, v2 ); }
I'm not surprised, third party template libraries would have to be "expression template safe" to be used unchanged with mp_number, a typical example of what fails is: foo(a+b) where foo is a template function. This can only be fixed inside uBlas unfortunately.
Fails with MSVC 9 and a little old clang from thunk (--version prints clang version 3.2 (trunk 156987)).
The easy fix is to turn off expression templates inside mp_number.
It also fails even with expression templates being turned off whenever it tries to compare mp_number with a convertible type:
-------------------------
#include <boost/multiprecision/cpp_dec_float.hpp>
typedef boost::multiprecision::mp_number< boost::multiprecision::cpp_dec_float<50> , false > float_type;
struct A { operator float_type() const { return (float_type)1.0f; } };
int main(int argc, char* argv[]) { float_type f = 123.0f; A a;
bool r = (a < f); }
-------------------------
Such constructions appear sometimes within UBLAS (e.g., lu_factorize with NDEBUG undefined). The fix is probably non-trivial. I've successfully overcome it by modifying is_valid_comparison_imp:
Sigh... that's just nasty. I probably need to rewrite the comparison code anyway for better efficiency, I'll try and fix this along the way.
Also running the tests for UBLAS with mp_number put in place of floats/doubles would be interesting.
Nod, will try.
Do you think the library should be accepted as a Boost library?
Whenever issues with UBLAS interoperability are fixed (or some reasonable decision is made).
Many thanks for the feedback, John.