Here is another idea for the high level interfaces (and maybe even the lower level ones).<div><br><div>Right now, many of emails about &quot;bugs&quot; to the ublas lapack bindings have to do with row vs. column storage with the inevitable answer to use fortran storage.</div>
<div><br></div><div>One solution is to always static assert the storage ordering in all of the functions and break if they call it with row_major.</div><div><br></div><div>But can&#39;t we get &quot;partial&quot; support for row major by exploiting the lapack routines and the symmetry of certain routines?  For example:</div>
<div><ul><li>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&#39;t static assert under this circumstance</li><li>Many of the routines have a &quot;transpose&quot; option in the arguments.  Doesn&#39;t this allow us to change the storage ordering automagically within the wrapper for the routine?  See ?getrs for example.</li>
<li>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&#39;t even need to swap out any settings to use column_major?</li>
<li>I don&#39;t know how feasible these kinds of things are for packed storage.</li></ul></div><div>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).</div>
<div><br></div><div>-Jesse</div></div>