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