[Dune-devel] [GSoC2016] Wrapper for the FieldMatrix class

[Andreas Dedner]

Hi


> 
> However, I have some interrogations about the leftmultiplyany and
> rightmultiplyany methods. Both of them introduces a new template
> parameter which defines the number of rows or columns of the second
> FieldMatrix. And I just jumped to the conclusion that there as no
> elegant way to deal with it.In fact, this template parameter which
> defines the number of rows or columns of the second FieldMatrix must be
> specialized at compile time and it means registering all the matrices
> that can be multiplied by the others...
> 
> So actually with my wrapper, you can just multiply a matrix by a square
> matrix with the same dimension of rows/columns. Is that okay? I grepped
> "leftmultiplyany" and "rightmultiplyany" with "grep -R" on all the core
> modules of DUNE and these methods are not used anywhere (except in the
> files where they are defined and in the related test files). So I assume
> it is not very important to provide bindings for them?
> 
> I think it matters to have some discussion about that because it would
> give me some leads about the fact to do such "compromises" about
> templated methods like that (I guess I will have the same problem on
> other classes soon enough).
> 

I agree that we will have to think carefully about these details during
the course of this project. Perhaps starting out with distinguishing
different places where the FieldMatrix/Vectors are used. For example
they are important for the grid geometry classes (used for the
jacobianInverseTranspose method for example). Here the most important
cases are n x n and then perhaps 1xn, nx1 and 2xn,nx2. If we can cover
the most important cases that would already be helpful.

Btw: I just came across this

http://www.boost.org/doc/libs/1_57_0/libs/python/doc/v2/indexing.html#vector_indexing_suite

which might be of interest. I think FieldVector/Matrix do not quite
satisfy the std::vector interface at the moment (I know for example that
difference_t is missing) but perhaps we can add the missing items to the
classes. This might provide quite a nice approach for the wrapping.

I came across this in the following discussion which has a nice summary
of some of the problems encountered when wrapping C++ containers:

http://stackoverflow.com/questions/27077518/wrapping-an-stdvector-using-boostpython-vector-indexing-suite

Best
Andreas