dolfin team mailing list archive

["Garth N. Wells" <gnw20@xxxxxxxxx>]

Johan Hake wrote:
> 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.
> 

Can you give us a short tutorial on NumPy and memory management, namely:

1. If a Numpy object is created from an point to a double, will NumPy
ever destroy the data?

2. If the pointer to the NumyPy data is used to create say an Array
object, can the Numpy object be stopped from destroying it, or do we
need to make a copy?

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

I think that we should allow resizing.

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

This sounds easy.

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

This would involve extending Array with the member function 'array' in
the SWIG code?

Would the function array create a NumPy view of the data, or would the
NumPy object already  exist (i.e., be created in the interface when
moving the object from C++ to Python)?

This option sounds more complicated, but could be nice if it works such
that if a NumPy object is not required, it is never constructed.

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

I'm not sure.

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

Great. We can tweak the Array class as needed. I expect that we'll need
some functions to deal with memory management in the wrapper code.

Garth

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