Re: [ublas] [bindings][lapack] Interface design

Subject: Re: [ublas] [bindings][lapack] Interface design
From: jesseperla_at_[hidden]
Date: 2008-12-03 15:34:11

This looks so beautiful. The matlab morons converting to C++, like myself,  
would love something along these lines. I have a lot of trouble figuring  
out if a particular LAPACK function is implemented, and am unable to  
understand the source code well enough to see what the subtly different  
naming conventions are to call it. And if there is any way to add in  
overloaded versions that returns the object as an alternative, that would  
be amazing as well and make matlab porting even easier. For example:
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