> I would prefer to leave this sort of usability features to matrix libraries like GLAS or MTL4. The numeric bindings library would be in a very unfortunate situation when trying to > figure out the desired return type, and even if it where able to figure it out, it would still not know how to call its constructors...

But by adding in the interfaces as proposed by Rutger, this is already getting into the usability game somewhat.  I would love to have a fully implemented GLAS, etc. but it is far off.  And most people see boost::ublas and an eventual ublas bindings in boost as the primary combination to make C++ a worthy replacement for matlab, and superior in semantics to fortran.  And if there is little extra effort in generating a few alternatives through overloaded functions within a generation script, then perhaps it is worth considering when designing the interface at this stage.  Returning as values is gravy, but I think it is worth looking at usability in general for the interfaces since most people would want to just use it directly.  Plus is it reasonable to think that people will layer ublas, ublas bindings, GLAS, and an underlying LAPACK to get basic linear algebra operations done?  Sounds like a lot of moving pieces for most people, certainly including me.

>Please don't get me wrong, but the numeric bindings library is currently not focused on people believing that the left eigenvalues of a matrix are different from its right eigenvalues. >So it's certainly good when one can learn something from Matlab about making the interface easier to use, but the focus should stay on providing C++ bindings against existing >external libraries.

Ooops, brain fart.  Meant left/right eigenvectors and related matricies of course.

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