Re: [ublas] [bindings][traits] is_vector, is_matrix

Subject: Re: [ublas] [bindings][traits] is_vector, is_matrix
From: Jesse Perla (jesseperla_at_[hidden])
Date: 2009-03-11 17:07:15

> My vote would be to collapse things into short names e.g. eig(),
> solve() as much as it is possible to distinguish the different forms
> based on the types of the input arguments.

My vote would be weakly the same.  Sure, you want people to think through
the problem to use the right algorithm... but isn't that usually implicit in
the structure of the input matrices?  The first-order problem with matlab I
have seen is that people don't use the right type of matrix.

Speaking of which...  The bindings for ?tritri don't seem to work as one
would expect for triangular matrices.  The following code works:
ublas::matrix<double, ublas::column_major> (A2,2);
A(0,0) = 1.0;
A(1,0) = 1.0; A(1, 1) = 2.0;
A(0, 1) = 0.0; //Shouldn't need, but good to set
lapack::trtri('L', 'N', A);

But the following won't compile, which has the triangular matrix one would
expect to work:

ublas::triangular_matrix<double, ublas::lower, ublas::column_major> A(2,2);
A(0,0) = 1.0;
A(1,0) = 1.0; A(1, 1) = 2.0;
lapack::trtri('L', 'N', A);

The new bindings seem to compile and my basic test cases worked.  I still
don't really know what is going on with the workspace stuff, but should the
following code (which compiles) work? (it pops out a different number than
matlab, but I could be misinterpreting the results):

ublas::matrix<double, ublas::column_major> A(2,2);
//First need to call getrf()
std::vector<int> ipiv (2);  // pivot vector
lapack::getrf(A, ipiv);
//Then can get the inverse
lapack::getri(A, ipiv, lapack::optimal_workspace() );

... optimal_workspace() is compiling now, but is it working?