|
|
Ublas : |
Subject: Re: [ublas] [bindings] New traits system
From: Rutger ter Borg (rutger_at_[hidden])
Date: 2010-01-08 16:33:02
Jesse Perla wrote:
> Looks great so far Rutger!
Thanks!
> In particular, trtri, using normal matrix storage needs an uplo tag.
> Since this
> wouldn't be available for a regular ublas::matrix, I assume I need to use
> the
> ublas::triangular_adaptor to add on a tag. The trait is not picked up (or
> implemented?) for this type.
Thanks. I just did a sync of the LAPACK bindings, I haven't committed them
for a while until I was sure the new traits / bindings were good enough. I
guess now they are. Please check out the latest trtri.
* numeric/bindings/ublas/triangular.hpp should bring in support for native
ublas triangular matrices (which are packed). This header also includes
support for the ublas triangular adaptor.
* numeric/bindings/upper.hpp, numeric/bindings/unit_upper.hpp,
numeric/bindings/lower.hpp and numeric/bindings/unit_lower.hpp should give
you a shortcut for the triangular adaptors you have been using.
E.g.,
matrix_type a;
lapack::trtri( bindings::upper( a ) );
or
lapack::trtri( bindings::unit_lower( a ) );
should do the trick. If you see an uplo tag as a char argument somewhere,
it's a bug in the generator. I haven't been able to thoroughly test these
wrappers yet, I would be curious to hear if they work like they should.
> Similarly, with tptri requiring packed storage, I used a
> ublas::triangular_matrix, but it didn't hit the "uplo" tag.
AFAICT, the generator picked up this one correctly, too. Please checkout the
subversion repository.
> Also, I have a question: If combined with "auto" and "decltype", and a
> couple
> of wrapper functions around result_of::, the traits are looking
> suspiciously
> close to a generic interface for linear algebra (like GLAS?).
> This sure would be nice to have in one form or another. Do you see this
> as part
> of the traits system? I sure would love to write code independent of
> matrix
> libraries.
With respect to your first question, what do you mean with a generic
interface?
The aim of the bindings would be to keep a separation of data structures
from algorithms. The traits are the glue, this is also the reason why I've
moved the traits part into the "root" of the bindings.
Indeed, being able to write algorithms independent of matrix libraries has
been a motivation for rewriting the traits. There's already support for
iterators to raw data, and for objects with data in linear arrays. This will
have to be extended to the other data storage layouts and matrix types. Add
a function like "at" for accessing elements by indices, and I say we're in
business for writing generic algorithms.
Suggestions and/or comments are most welcome,
Cheers,
Rutger