this is great but has one disadvantage, it does not allow runtime polymophism.|
this is great but has one disadvantage, it does not allow runtime polymorphism.|
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
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 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.
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
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.