dolfin team mailing list archive

[Johan Hake <johan.hake@xxxxxxxxx>]

On Sunday 06 December 2009 07:23:27 Garth N. Wells wrote:
> Anders Logg wrote:
> > On Sun, Dec 06, 2009 at 12:46:53PM +0000, Garth N. Wells wrote:
> >> Anders Logg wrote:
> >>> Shouldn't this be templated? This could be used also for passing uint
> >>> arrays to and from Python.
> >>
> >> It probably should be, but it may make things more complicated on the
> >> SWIG side. Perhaps Johan H. could comment - not on whether it's possible
> >> (I'm sure for Johan that it is), but on whether or not it's easy.
> >>
> >> Templating it would be better on the C++ side, not just for double, int,
> >> etc, but to handle const pointers correctly.
> >
> > ok.
> >
> >>> I imagine we can typedef
> >>>
> >>>   DoubleArray
> >>>   UintArray
> >>
> >> This is a bit ugly. Might as well just use Array<double>, Array<uint>,
> >> etc.
> >
> > I agree it's ugly. I didn't suggest it for use in C++ but that it
> > might simplify for the wrapper generators but when I think of it
> > again, it probably makes no difference for SWIG.
> 
> As a start, we can declare the templates with these names in SWIG, and
> SWIG will wrap the member functions and it should work out of the box
> (with a few tweaks for [] and =).

We can make the Array class templated. We can also specialize SWIG interfaces 
for the a particular Array<Foo> class dependent on what Foo is. If it is a 
primitive (double, uint) we can expand the class with a set of constructors, 
utility methods, and typemaps which should make it easy to interact with 
NumPy. However we need to cover all possible cases of such extensions wrt to 
memory handling and difference in intent use.

In particular will we need to decide what we want the argument: Array<Foo> & 
to do. If we know a method will not resize the argument, we can just map the 
content to the NumPy pointer. If we allow resize we can either turn the 
argument into a pure out argument, i.e., we construct the Array<Foo> in the 
interface, pass it to the C++ method, and when it is returned, create a NumPy 
array which takes ownership of the data and pass this to Python. Or we can let 
the user pass an instance of ArrayFoo to the method, and use ArrayFoo.array() 
to get a NumPy view of the data. 

Note that we can have both of these typemaps (for the same Foo) at the same 
time in PyDOLFIN, by either using specific argument names for the two 
different cases:

  Array<Foo> & values
  Array<Foo> & values_resize

or we need to construct module specific typemaps, which might get out of 
hands, when things get complicated.

Garth do you suggest we also use Array<const Foo*> to pass what we now use 
std::vector for (DirichleBC, GenericFunction, aso)? Would this work from the 
C++ side? We loose the push_back functionality from std::vector. If you think 
we go for Array<const Foo*> it is no big deal creating specific typemaps for 
this.

As soon as I am able I can add NumPy typemaps for the most straightforward 
cases.

Johan


> Later, we can provide typemaps for cases where we want to map an Array
> to a NumPy array.
> 
> Garth
> 
> > --
> > Anders
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~dolfin
> Post to     : dolfin@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~dolfin
> More help   : https://help.launchpad.net/ListHelp
>