Extensions And New Usage Patterns In UBLAS

BOOST WIKI | RecentChanges | Preferences | Page List | Links List

uBLAS Extensions and new usage patterns

Simplifying internal syntax

Can matrix_matrix_binary_traits<x1::value_type, x2, x2::value_type, x2> be shorted by droping the value_type and using only 2 parameters for the default case?

Implementing prod for Symmetric Positive Definite forms: XX' and XS*X'

A couple of properties make these forms special.

The result is always symmetric
X*X' is a row only operation

It would be nice to use the uBLAS ET mechanism to define a composite 'prod_SPD' that compose these functions from the existing function. That is prod_SPD returns an ET type. Problems:

1. The last step requires that the result is symmetric. But symmetric_adaptor does not work. It is a container addaptor and not an ET compositior.

2. The inner product of X*S should use a temporary. But this temporay is the return value of prod<>; It will be referenced in the ET built by the function. When the function exits it is out of scope! NASTY

sparse and proxy semantics for iterators are inconsistently defined

Iterating over a sparse matrix iterates only over the non zero elements. Iterating over a proxy (eg. symmetric_adaptor) iterates over the defined shape of the matrix (upper or lower). When combined these two definitions are inconsistent. Therefore a symmetric proxy to a sparse matrix results in an iterator with two meanings.

This a hard problem to fix for matrices. Firstly for efficiency (see conformant sparse proxies), secondly the assignment function must be specialised to avoid over assignment.

For vector storage the case is different. There are no shape constraints possible! However matrix proxies also produce vector types. A row_proxy of a symmetrix_adaptor of a sparse_matrix may be a tough problem!!

uBLAS for specification of generalised BLAS expression

The above prod_SPD example leads to an interesting question. Can uBLAS experssion templates be used generate meta expressions. That is, can you use the ET mechanism to heirachically build a type that represents a BLAS expression for latter evalutation.

uBLAS is not designed for this. The ET compositors, containers, and adaptor types work at different level. Some build expressions some evalutate them. The prod_SPD example show this.

Polymorphic uBLAS

uBLAS gets much of its efficiency from compile time selection of generic algorithms based on type traits of its containers. Obviously this is great but has one disadvantage, it does not allow runtime polymorphism. That is, the matrix containers in uBLAS all have a fixed storage and access methods that is encoded into their type.

Can uBLAS be extended to deal with matrix/vector containers that are runtime polymorphic?

I would envision two types: any_vector and any_matrix that can hold any of the existing uBLAS container types. At the application layer it would allow:

 my_function (any_matrix& am, any_vector& av)

instead of

 template<class M, class V>
 my_function (M& am, V& av)

The aim would be to allow any matrix type (dense packed or sparse). There are two possible implemenations

Easy solution: Mirror the present sparse_ scheme. Make

the any_ types appear to uBLAS as sparse (whatever their runtime time). Therefore using the most general algorithms in uBLAS. This would be slow. Not much advantage over always using sparse_ types.

Hard solution: Mirror the present static scheme so that

the most efficient algorithm is chosen at runtime depending on the runtime type of the any_ containers envolved

Further information from Joerg related to the second solution

1. Glommable expression templates

Geoffrey Furnish extended the ET machinery to allow to adapt external containers without ambiguities. I've been playing with this ansatz in the past,but rejected it. I still don't know if it could be worth the effort.

Comment: Disambiguation can be achieved without touching the class design, see e.g. a first try at http://daixtrose.sf.net Disambiguation is a completely orthogonal feature and yes, it should be used to avoid hassle. IMHO it is worth the effort. -- Markus Werle

2. Template metaprogramming

I'd like to use more template metaprogramming techniques mainly to reduce the code base of uBLAS, but this would be hazardous mainly because we agree to continue to support non compliant compilers.

Disclaimer: This site not officially maintained by Boost Developers