[ublas] [bindings][lapack] Initial high-level solve

Subject: [ublas] [bindings][lapack] Initial high-level solve
From: Jesse Perla (jesseperla_at_[hidden])
Date: 2009-03-28 20:44:34

Here is another idea for the high level interfaces (and maybe even the lower
level ones).
Right now, many of emails about "bugs" to the ublas lapack bindings have to
do with row vs. column storage with the inevitable answer to use fortran
storage.

One solution is to always static assert the storage ordering in all of the
functions and break if they call it with row_major.

But can't we get "partial" support for row major by exploiting the lapack
routines and the symmetry of certain routines?  For example:

   - If we are using a routine expecting a square dense symmetric matrix ,
   then does it matter if we pass in a row or column major matrix?  We probably
   shouldn't static assert under this circumstance
   - Many of the routines have a "transpose" option in the arguments.
    Doesn't this allow us to change the storage ordering automagically within
   the wrapper for the routine?  See ?getrs for example.
   - For a whole bunch of linear algebra algorithms, the solution for a
   matrix is the same as the solution for its transpose (determinants, rank,
   etc.) so for those we don't even need to swap out any settings to use
   column_major?
   - I don't know how feasible these kinds of things are for packed storage.

I realize that many of these things may be tough to automatically generate
from the python generator, but perhaps they could be done for the higher
level routines.  It would be really nice if we could use row major matrices
where possible, especially since many people may be concurrently using
routines in other bindings/functions that require row major matrices (I know
I have some).

-Jesse