Question

I am using CodeSourcery’s implementation of the vector signal image processing library (vsipl++). I have written a function that is supposed to return [I + a*A]^-1 B, where I is the identity matrix, and A and B are compatible square matrices, as follows:

namespace vsipl {

template< class T1, class T2, class O1, class O2, class L1, class L2,
     template< dimension_type, class, class, class > class B1,
     template< dimension_type, class, class, class > class B2 >
Matrix< typename Promotion< T1, T2 >::type, 
        B1< 2, typename Promotion< T1, T2 >::type, O1, L1 > > 
inv_mult( typename Promotion< T1, T2 >::type a, 
       Matrix< T1, B1< 2, T1, O1, L1 > > const& A,
       Matrix< T2, B2< 2, T2, O2, L2 > > const& B
     ) 
{
 typedef typename Promotion< T1, T2 >::type value_type;
 typedef Matrix< value_type, B1< 2, value_type, O1, L1 > > ret_type;
 typedef lud< value_type, by_reference > lud_type;

 ret_type ret(A.size(0),A.size(1),0), denom(A.size(0),A.size(1),0);

 //I + a*A
 denom.diag() = 1;
 denom = denom + a*A;

 lud_type ld( denom.size() );
 ld.decompose( denom );

 //as a side effect of using LAPACK as a back end, this requires a template
 //param to indicate precisely what is being solved.
 ld.solve< mat_ntrans >( B, ret );  // <--- Line generating error.

 return ret;
}//inv_mult
}//vsipl

To be clear, in vsipl++ Matrices accept two parameters: a type and a block which describes how the information is stored. The block is the cause of the template soup, above. Also, the lud object performs an LU decomposition on a matrix, A, and then solves Ax = b using the decomposed form of A.

When I try to compile this using gcc (both 4.2.1 on MacOs 10.6 and 4.3.0 on Fedora 9) I get the following error

error: no match for 'operator<' in 'ld.vsip::lud<T, by_reference>::solve [with 
 vsip::mat_op_type tr = tr, Block0 = Block0, Block1 = Block1, T = double] < mat_ntrans

I’ve tried simplifying the code by eliminating the type Promotion‘s, requiring a single data and block type, and I get the same error.

Any thoughts?

Answer 1

try

ld.template solve< mat_ntrans >

explanation, because the same thing made me crazy