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 : [email protected] > Unsubscribe : https://launchpad.net/~dolfin > More help : https://help.launchpad.net/ListHelp > _______________________________________________ Mailing list: https://launchpad.net/~dolfin Post to : [email protected] Unsubscribe : https://launchpad.net/~dolfin More help : https://help.launchpad.net/ListHelp
