[vsipl++] QR Solver
Jules Bergmann
jules at codesourcery.com
Thu Nov 2 14:37:40 UTC 2006
Assem,
This looks good. Can you address the comments below and then check
it in?
thanks,
-- Jules
Assem Salama wrote:
> Everyone,
> This patch implements the QR backend using Cvsipl.
>
> Thanks,
> Assem
>
>
> ------------------------------------------------------------------------
>
> Index: src/vsip/core/cvsip/solver_qr.hpp
> ===================================================================
> +/// Qrd implementation using CVSIP
> +
> +/// Requires:
> +/// T to be a value type supported by SAL's QR routines
[1] Change reference to C-VSIPL (instead of SAL).
> +
> +template <typename T,
> + bool Blocked>
> +class Qrd_impl<T, Blocked, Cvsip_tag>
> +{
> + typedef vsip::impl::dense_complex_type complex_type;
> + typedef Layout<2, col2_type, Stride_unit_dense, complex_type> data_LP;
[2] Please change this to row2_type.
col2_type was necessary for Lapack. For C-VISPL, either row2_type or
col2_type will work. Since most user data will be row-major, using
row2_type will avoid the need for a transpose in the common case.
> + typedef Fast_block<2, T, data_LP> data_block_type;
> + // Member data.
> +private:
> + typedef std::vector<T, Aligned_allocator<T> > vector_type;
[3] remove this (unused) typedef.
> +
> + length_type m_; // Number of rows.
> + length_type n_; // Number of cols.
> + storage_type st_; // Q storage type
> +
> + Matrix<T, data_block_type> data_; // Factorized QR(mxn) matrix
> + cvsip::Cvsip_matrix<T> cvsip_data_;
[4] Please use cvsip::View<2, T, true> instead of Cvsip_matrix.
> + cvsip::Cvsip_qr<T> cvsip_qr_;
> +};
> +#endif // VSIP_CORE_CVSIP_SOLVER_QR_HPP
> Index: src/vsip/core/cvsip/cvsip.hpp
> ===================================================================
> +// some support defines
[5] First, anything we #define has to be prefixed with VSIP_ (if it
is in the spec) or VSIP_IMPL_ (if not).
Second, these following macros should be inline functions. In C++
inline functions are just as efficient as macros, and they don't have
all the downsides.
> +#define get_vsip_st(st) \
> + ( (st == qrd_nosaveq)? VSIP_QRD_NOSAVEQ: \
> + (st == qrd_saveq1)? VSIP_QRD_SAVEQ1: \
> + VSIP_QRD_SAVEQ \
> + )
> +
> +#define get_vsip_side(s) \
> + ( (s == mat_lside)? VSIP_MAT_LSIDE:VSIP_MAT_RSIDE )
> +
> +#define get_vsip_mat_op(op) \
> + ( (op == mat_ntrans)? VSIP_MAT_NTRANS: \
> + (op == mat_trans)? VSIP_MAT_TRANS: \
> + VSIP_MAT_HERM \
> + )
> +
> } // namespace cvsip
>
> } // namespace impl
> Index: src/vsip/core/cvsip/cvsip_qr.hpp
> ===================================================================
> +template <typename T>
> +class Cvsip_qr;
[6] Please remove this forward declaration. It isn't necessary, since
the definition follows immediately.
> +
> +template <typename T>
> +class Cvsip_qr : Non_copyable
> +{
> + typedef typename Cvsip_traits<T>::qr_object_type qr_object_type;
> +
> + public:
> + Cvsip_qr<T>(int m, int n, vsip_qrd_qopt op);
> + ~Cvsip_qr<T>();
[7] Please name the constructor 'Cvsip_qr' instead of 'Cvsip_qr<T>'.
Likewise for the destructor.
This is consistent with all the other class definitions in the
library. Technically, referring to the class as 'Cvsip_qr<T>' is OK.
However, this style will become burdensome for classes with many
template parameters.
--
Jules Bergmann
CodeSourcery
jules at codesourcery.com
(650) 331-3385 x705
More information about the vsipl++
mailing list