Re: [boost] [review] Multiprecision review (June 8th - 17th, 2012)

Subject: Re: [boost] [review] Multiprecision review (June 8th - 17th, 2012)
From: John Maddock (boost.regex_at_[hidden])
Date: 2012-07-30 08:18:36

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