- On Tuesday 25 March 2003 17:26, Kresimir Fresl wrote:
> Some time ago Toon wrote in boost-ml:

I don't believe it's feasible. When implementing the bindings I found it to be very subtle.

>

> ``Note that the bindings are not complete but the 'framework' is there

> and it's just a matter of time to complete them.''

>

> Bindings are mostly a free-time activity. Or, one can say that we

> try to generalize some more or less ad-hoc parts of our `regular' work.

> So `matter of time' probably means `some (considerable) time' :o(

>

> > Some kind of meta program to generate lapack interfaces from a parameter

> > spec would be nice (ruby/perl?

>

> Interesting idea.

For instance, lapack functions might have different signatures depending on the

value_type.

> > or just a description of what needs to be

All help is welcome. As Kresimir will mention later in this email,

> > done) Then I could happily bring up the interfaces I need.

>

> As I said, bindings are free-time activity, so any help is

> welcomed.

the current implementation is not standard conforming. So if you care

to help, we can launch the discussion on how we best implement

the bindings and start working on it together.

> Lapack bindings are Toon's realm, but I hope that my understanding

Thanks for responding to this question while I was enjoying snowboarding.

> is good enough to (try to) explain what needs to be done.

You practically write the whole documentation in a single email ;-)

> [1] I think that this interface [i.e. func (matrix&, begin_iter,

Agreed !

> end_iter)] is

> mixing of two idioms -- why STL's idiom of iterator ranges [begin, end)

> here, and not for other vectors in e.g. blas 1&2 bindings?

> Interface of getrf in atlas bindings (atlas/clapack.hpp) is simply:

>

> int getrf (MatrA& a, IVec& ipiv);

> [2] It is true that both ublas::matrix<> and TNT::Array2D<> define

Agreed !

> value_type, but (in ideal world ;o) bindings should work for other

> matrix types which can have val_t or something else.

> And that's why we have matrix_traits; so, instead of

>

> typedef typename matrix_type::value_type value_type ;

>

> it should be

>

> typedef typename matrix_traits<matrix_type>::value_type value_type;

> [3] See the interface of getrf in atlas bindings (atlas/clapack.hpp)

I admit that it's a bit clumsy while trying to avoid code duplication.

> for IMHO more elegant way to do this (yes, I'm probably biased ;o)

> > I have one worry: Ublas, and most of the boost modules, seems to me

Joerg,

> not for

> > the faint hearted. They are clearly powerful, but seem to expect a lot

> > from a potential user.

>

> Well, some boost libraries are certainly frightening, but I don't think

> that ublas is among them -- its interface seems rather intuitive.

You know what I appreciate even more than the documentation: a small

comment on all classes and their member function.

> > but I want to use boost and I am worried that it may be too demanding

powerfull things might be difficult to understand at first but ... hey they are powerfull.

> for

> > its benefites to be justified for use by the group of people I work

> with.

>

You might achieve the same goal writing more code but that takes time.

You can just as well walk your whole life but take the time to learn how to drive

a car and you will get there much faster (but you first need to invest the time to

learn to drive a car). I understand your concern but I'm convinced that investing

in a well established library is worth it.

toon - Hi Matthias (hi all),

you wrote:

> After some discussions in my group when we had Jeremy Siek visit this

I've been thinking about the lapack bindings for some time now and I believe

> weekend we agreed that we would like to see generic C++ lapack

> interfaces that work with ublas and other matrix libraries submitted to

> boost as a library. One could start with the high level driver

> functions only and add more specialized functions later. I thus would

> like to ask what the current status of the ublas lapack bindings is and

> if somebody is working on a generic version for boost, or if my

> research group could help here?

it's firstly necessary to limit the scope of investigation.

The LAPACK users guide distinguishes the following parts:

<cite>

(1) Linear Equations

(2) Linear Least Squares (LLS) Problems

(3) Generalized Linear Least Squares (LSE and GLM) Problems

(4) Standard Eigenvalue and Singular Value Problems

(a) Symmetric Eigenproblems (SEP)

(b) Nonsymmetric Eigenproblems (NEP)

(c) Singular Value Decomposition (SVD)

(5) Generalized Eigenvalue and Singular Value Problems

(a) Generalized Symmetric Definite Eigenproblems (GSEP)

(b) Generalized Nonsymmetric Eigenproblems (GNEP)

(c) Generalized Singular Value Decomposition (GSVD)

</cite>

This structure seems to suggest some splitting into sublibraries or

namespaces. Which parts are most important?

Golub & van Loan reference the following procedures:

Chapter 3:

(1) _TRSV, _TRSM, _TRCON, _TRRFS, _TRTRS, _TRTRI

(1) _GESV, _GECON, _GERFS, _GESVX, _GETRF, _GETRS, _GETRI, _GEEQU

Chapter 4:

(1) _GBSV, _CGBCON, _GBRFS, _GBSVX, _GBTRF, _GBTRS, _GBEQU

(1) _GTSV, _GTCON, _GTRFS, _GTSVX, _GTTRF, _GBTRS

(1) _POSV, _POCON, _PORFS, _POSVX, _POTRF, _POTRS, _POTRI, _POEQU

(1) _PBSV, _PBCON, _PBRFS, _PBSVX, _PBTRF, _PBTRS

(1) _PTSV, _PTCON, _PTRFS, _PTSVX, _PTTRF, _PTTRS

(1) _SYSV, _SYCON, _SYRFS, _SYSVX, _SYTRF, _SYTRS, _SYTRI

(1) _TBCON, _TBRFS, _TBTRS

Chapter 5:

(?) _LARFG, _LARF, _LARFX, _LARFB, _LARFT

(?) _LARTG, _LARGV, _LARTV, _LARSR, CSROT, CROT, CLACGV

(?) _GEQRF, _GEQPF, _ORMQR, _UNMQR, _ORGQR, _UNGQR

(?) _GERQF, _GELQF, _GEQLF, _TZRQF

(4.c) _GESVD, _BDSQR, _GEBRD, _ORGBR, _GBBRD

(2) _GELS, _GELSS, _GELSX, _GEEQU

Chapter 7:

(4 b) _GEBAL, _GEBAK

(4 b) _GEHRD, _ORMHR, _ORGHR, _UNMHR, _UNGHR

(4 b) _HSEQR, _HSEIN

(4 b) _GEES, _GEESX, _GEEV, _GEEVX

(4 b) _TREVC, _TRSNA, _TREXC, _TRSEN, _TRSYL

(5 b) _GGBAL, _GGHRD, _HGEQZ, _TGEVC, _GGBAK

Chapter 8:

(4 a) _SYEV, _SYEVD, _SYEVX

(4 a) _SYTRD, _SBTRD, _SPTRD

(4 a) _STEQR, _STEDC, _STERF, _PTEQR, _STEBZ, _STEIN

(?) _SYGST, _PBSTF, _SBGST

(4 c) _GESVD, _BDSQR, _GEBRD, _ORGBR, _GBBRD

(5) _GGSVP, _TGSJA

My classification currently is an educated guess only ;-) If I count these

function correctly, I still find an astonishing number of around 130 ;-( To

get any clue of how to proceed I believe we have no other chance than to

follow Kresimir's suggestion to invent names for the corresponding families

of overloaded functions or specialized classes. If nobody else is

interested, I'll try to come up with a proposal after some more scanning...

All the best,

Joerg

P.S.: I didn't see any definitive motion for your idea to wrap up the driver

routines first, so this is kind of an alternative ansatz.

P.P.S.: How are we able to test these wrappers?