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

[Michaël Sghaïer]

Dear duners,

 As Martin has suggested me:

2016-03-21 4:09 GMT-04:00 Martin Nolte <nolte at mathematik.uni-freiburg.de>:

> As Andreas already said, wrapping a few more methods might be interesting,
> too. You could also have a look at the FieldMatrix, especially at the
> operator[] (which returns a reference to a FieldVector).
>

I am working on a (Boost.Python) wrapper for the FieldMatrix class and you
can find the code on the gitlab [1].

Like my first junior job (a wrapper for the FieldVector class), I have to
deal with static polymorphism and C++ templates. Thus, I used the same
skeleton with a WrapFieldMatrix class, which defines a WrapFieldMatrix()
constructor, called inside a BOOST_PYTHON_MODULE macro to specialize this
class at compile time.

See the result, within a python interpreter:

>>> from libfmatrix import *
> >>> m = FieldMatrix11(3.14)
> >>> m
> <libfmatrix.FieldMatrix11 object at 0x7fa692add030>
> >>> m.mat_access(0)
> <libfvector.FieldVector1 object at 0x7fa692acdf80>
> >>> m.mat_access(0)[0]
> 3.14


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).

Anyway, I am going to continue my work by writing some documentation and
unit tests and think about how to handle exceptions (because for now, you
can do out of bonds accesses without any "trouble", which is kind of
disturbing).

Best,

Michaël

[1]
https://gitlab.dune-project.org/michael.sghaier/dune-common/commit/22e9c16ff0bb536e7c844f8be10d71e80f7fc4e2
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dune-project.org/pipermail/dune-devel/attachments/20160326/ca47c7f4/attachment.htm>