Boost logo

Ublas :

Subject: Re: [ublas] [bindings][lapack] Interface design
From: Jesse Perla (jesseperla_at_[hidden])
Date: 2008-12-03 18:22:48


> I would prefer to leave this sort of usability features to matrix
libraries like GLAS or MTL4. The numeric bindings library would be in a very
unfortunate situation when trying to > figure out the desired return type,
and even if it where able to figure it out, it would still not know how to
call its constructors...

But by adding in the interfaces as proposed by Rutger, this is already
getting into the usability game somewhat. I would love to have a fully
implemented GLAS, etc. but it is far off. And most people see boost::ublas
and an eventual ublas bindings in boost as the primary combination to make
C++ a worthy replacement for matlab, and superior in semantics to fortran.
And if there is little extra effort in generating a few alternatives through
overloaded functions within a generation script, then perhaps it is worth
considering when designing the interface at this stage. Returning as values
is gravy, but I think it is worth looking at usability in general for the
interfaces since most people would want to just use it directly. Plus is it
reasonable to think that people will layer ublas, ublas bindings, GLAS, and
an underlying LAPACK to get basic linear algebra operations done? Sounds
like a lot of moving pieces for most people, certainly including me.

>Please don't get me wrong, but the numeric bindings library is currently
not focused on people believing that the left eigenvalues of a matrix are
different from its right eigenvalues. >So it's certainly good when one can
learn something from Matlab about making the interface easier to use, but
the focus should stay on providing C++ bindings against existing >external
libraries.

Ooops, brain fart. Meant left/right eigenvectors and related matricies of
course.

> Last, is there any way you can throw an exception if the matrix traits
> doesn't have fortran column-major ordering in the bindings for LAPACK?
Yes, far better of course. And I think this one is really worth
implementing sooner rather than later.

As a last question, with the current implementaiton is there a standard way
to search to see if a lapack funciton is implemented given its fortran
LAPACK name? Is there a single source file or approach to get at this? I
get confused... and it might be worth a note on a wiki somewhere of how to
check if it exists, and understanding how it would be called.

Thanks,
-Jesse