[ublas] [bindings][lapack] Interface design

Subject: [ublas] [bindings][lapack] Interface design
From: Rutger ter Borg (rutger_at_[hidden])
Date: 2008-12-01 06:16:58

All,

I've been working on the python lapack-bindings generator. Based on the
comments in the lapack source files, the script is now able to make
statements about integers that may be describing properties of the matrices
and vectors. Deduction of asserts and workspace sizes are on their way of
being done. See below for two examples of deduction of meaning of integers.

I've been looking into how most the lapack bindings have been written, and
the overall design, and its user interface. Some points I would like to
address so we will be able to take these bindings to their next level:

 * What consistent argument-interface are we going to offer to the user?
What I mean here, is making the path consistent when extra arguments are
made available to the user. For example, let's take a look at gesdd: 

  gesdd( A, s )
  gesdd( A, s, U, VT ) // OK, stuff on the right of previous arguments
  gesdd( Jobz, A, s, U, VT ) // Jobz on the left of prev. arguments?
  gesdd( Lw, Jobz, A, s, U, VT) // Again, on the left
  gesdd( Jobz, A, s, U, VT, w, iw ) // Here, it's on the right again?

I would prefer agument extension paths which keep the first arguments on the
same place, like 

  gesdd( A, s )
  gesdd( A, s, U, VT )
  gesdd( A, s, U, VT, Jobz )
  gesdd( A, s, U, VT, Jobz, LW )
  gesdd( A, s, U, VT, Jobz, w, iw )

I think when having (nearly) automatically generated bindings, this argument
extension path should be very consistent, otherwise it becomes difficult to
implement :-). The benefit is that increased consistency will make the
library easier to use from a user perspective as well. A suggestion for a
good set of rules will help here.

 * The bindings give integer return value(s) in fortran and/or C-style.
Could this be improved by the introduction of C++ error-handling with
exceptions, or perhaps even better, implemented by Policies, see, e.g.,
http://tinyurl.com/6lmk2w.

 * I would like to propose that driver routines and computational routines
are split into their own files. E.g., GESV and GETRI are to be put in
gesv.hpp, getri.hpp, etc. I think this makes it easier for a user where to
find what function.

Please let me know your thoughts,
Kind regards,

Rutger

Examples:

DGELSD:
The following arguments can be deduced:
 * LDB can be deduced, it is ['leading dimension of B']
 * LDA can be deduced, it is ['leading dimension of A']
 * NRHS can be deduced, it is ['number of columns of B']
 * LWORK can be deduced, it is ['size of array WORK']

CGEEV:
The following arguments can be deduced:
 * LDA can be deduced, it is ['leading dimension of A']
 * LDVL can be deduced, it is ['leading dimension of VL']
 * N can be deduced, it is ['number of rows of A', 'number of columns of A']
 * LDVR can be deduced, it is ['leading dimension of VR']
 * LWORK can be deduced, it is ['size of array WORK']