Re: [ublas] compilation error using prod()

From: Paul C. Leopardi (leopardi_at_[hidden])
Date: 2005-09-14 08:18:35

Hi Michael,
Thanks for continuing to follow this up. My responses are below.
Best, Paul
On Tue, 13 Sep 2005 21:00, Michael Stevens wrote:
> Patrick, Paul, and anyone else!
>
> I have been thinking about this a bit further.
>
> At the moment we have several major compilers still interpreting the prod
> overloads differently. Also to me it looks like compiler implementing DR214
> will never choose the prod<temp_type> overload as unambigeous.
>
> I think the solution in uBLAS must be to drop these overloads and remove
> them from the documentation. The "temp_type(prod(" form is a suitable
> alternative.

OK. GluCat, in matrix_imp.h, uses a similar construction, which looks like it 
has not been affected by the problems with the prod<temp_type> overload. 

  /// Product of sparse matrices
  template< typename LHS_T, typename RHS_T >
  inline
  const typename RHS_T::expression_type
  sparse_prod(const ublas::matrix_expression<LHS_T>& lhs,
              const ublas::matrix_expression<RHS_T>& rhs)
  {
    typedef typename RHS_T::expression_type matrix_t;
    return ublas::sparse_prod<matrix_t>(lhs(), rhs());
  }

Will you be changing sparse_prod() as well? If so, I will need to put #ifdefs 
in my code, since eg. 
    return matrix_t(ublas::sparse_prod(lhs(), rhs())); 
does not work with Boost 1.33.0 and gcc version 4.0.2 20050825 (prerelease).

../glucat/matrix_imp.h: In function ‘const typename RHS_T::expression_type 
glucat::matrix::sparse_prod(const 
boost::numeric::ublas::matrix_expression<E>&, const 
boost::numeric::ublas::matrix_expression<E2>&) [with LHS_T = 
boost::numeric::ublas::compressed_matrix<double, 
boost::numeric::ublas::basic_row_major<size_t, ptrdiff_t>, 0ul, 
boost::numeric::ublas::unbounded_array<size_t, std::allocator<size_t> >, 
boost::numeric::ublas::unbounded_array<double, std::allocator<double> > >, 
RHS_T = boost::numeric::ublas::compressed_matrix<double, 
boost::numeric::ublas::basic_row_major<size_t, ptrdiff_t>, 0ul, 
boost::numeric::ublas::unbounded_array<size_t, std::allocator<size_t> >, 
boost::numeric::ublas::unbounded_array<double, std::allocator<double> > >]’:
../glucat/matrix_multi_imp.h:393:   instantiated from 
‘glucat::matrix_multi<Scalar_T, LO, HI>& glucat::matrix_multi<Scalar_T, LO, 
HI>::operator*=(const glucat::matrix_multi<Scalar_T, LO, HI>&) [with Scalar_T 
= double, short int LO = -0x00000000000000020, short int HI = 32]’
../glucat/clifford_algebra_imp.h:182:   instantiated from ‘const 
Multivector<Scalar_T, LO, HI> glucat::operator*(const Multivector<Scalar_T, 
LO, HI>&, const RHS<Scalar_T, LO, HI>&) [with Multivector = 
glucat::matrix_multi, RHS = glucat::matrix_multi, Scalar_T = double, short 
int LO = -0x00000000000000020, short int HI = 32]’
../transforms/transforms.h:100:   instantiated from ‘void 
glucat_fast_test::time_fast(Multivector_T&, const Multivector_T&, const 
glucat_fast_test::index_set_t&, const glucat_fast_test::index_set_t&) [with 
Multivector_T = glucat::matrix_multi<double, -0x00000000000000020, 32>]’
../transforms/transforms.h:198:   instantiated from ‘void 
glucat_fast_test::fast_test(glucat::index_t, glucat::index_t) [with 
Multivector_T = glucat::matrix_multi<double, -0x00000000000000020, 32>]’
../transforms/transforms.h:233:   instantiated from here
../glucat/matrix_imp.h:200: error: no matching function for call to 
‘sparse_prod(const boost::numeric::ublas::compressed_matrix<double, 
boost::numeric::ublas::basic_row_major<size_t, ptrdiff_t>, 0ul, 
boost::numeric::ublas::unbounded_array<size_t, std::allocator<size_t> >, 
boost::numeric::ublas::unbounded_array<double, std::allocator<double> > >&, 
const boost::numeric::ublas::compressed_matrix<double, 
boost::numeric::ublas::basic_row_major<size_t, ptrdiff_t>, 0ul, 
boost::numeric::ublas::unbounded_array<size_t, std::allocator<size_t> >, 
boost::numeric::ublas::unbounded_array<double, std::allocator<double> > >&)’

> I still think the currect GCC 4.0.1 is odd as overloads defined with a
> simple template argument (say S) behave differently then those defined with
> expression<E>. This may be worth persuing as a bug report but I suspect
> given the history of DR214 this may be a long and hard process!

I still think it is worth filing a bug report. You never know. Maybe the bug 
has a fix which does not affect DR214.