matrix<double, column_major> A(3,3);

vector<double> b(3);

....

vector<double> x = lapack::solve(A,b); //allocates x internally and returns it, consistent with the ublas expression template syntax.... an extra object copy is reasonable for those who want to use this notation since it may not be possible to use the return value optimization

and...

tuple<vector<double>, vector<double> > my_eigenvalues = eigenvalues(A); //Both Left and right for example, or:

vector<double> left_eigen = left_eigenvalue(A);

Another thing is that I will often want to write generic functions that operate on matrices but may not be aware of their structure (other than row/column major), so this could help a great deal if the function looks at the ublas matrix traits/type.

For example, what I really want to do is (which may be what you meant in your interface suggestion):

symmetric_matrix<double, lower> A1 (3, 3);

hermitian_matrix<std::complex<double>, lower> A2(3,3);

mapped_matrix<double> A3(3, 3, 3 * 3); //For sparse

lapack::eigen( A1, left_eigen_values( vl ) );

lapack::eigen( A2, right_eigen( v ) ); //calls the hermitian routine

lapack::eigen( A3, right_eigen( v ) ); //calls the sparse routine.....

Last, is there any way you can throw an exception if the matrix traits doesn't have fortran column-major ordering in the bindings for LAPACK? This seems to be a constant source of bugs for everyone, and I am not sure I can see a case where you would want to call it without the proper ordering for LAPACK. If there are LAPACK implementations that take row-major, then perhaps those could be taken care of by a preprocessor instruction to swap which ordering it is testing for when compiling.

-Jesse