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

Subject: Re: [ublas] [bindings][lapack] Interface design
From: Karl Meerbergen (Karl.Meerbergen_at_[hidden])
Date: 2008-12-01 06:49:31

Hi Rutger,

Nice work. Another idea is to do it matlab style, i.e.
gesdd( A, s, options )
where options is an optional argument that contains the additional
information.
The default options correspond to gesd(A, s)

Karl

Rutger ter Borg wrote:
> 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']
>
>
>
> _______________________________________________
> ublas mailing list
> ublas_at_[hidden]
> http://lists.boost.org/mailman/listinfo.cgi/ublas
>