dolfin team mailing list archive

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

Anders Logg wrote:
> On Tue, Dec 01, 2009 at 09:59:18AM -0800, Johan Hake wrote:
>> On Tuesday 01 December 2009 00:45:50 Anders Logg wrote:
>>> Would it help to add a new class on the C++ side that is used only for
>>> passing array data back and forth between C++ and Python? We have had
>>> this before (SimpleArray) and it would be fairly easy to extend the
>>> C++ with extra functions in the interface that use SimpleArray instead
>>> of std::vector.
>>>
>>> Then perhaps we can have one single typemap that hits SimpleArray
>>> everywhere and converts it to a NumPy array.
>> Yes, something in that direction is what I had in mind. In addition we could
>> also add a foo.array() function to get a NumPy view from this class. This
>> would be nice when we do not want to have all the communication through
>> typemaps, but actually using the SimpleArray in Python as return argument from
>> some function that wants to resize the array.
>>
>> We would also need some stuff to handle memory management.
>>
>> I see two fundamental ways such a class could be used:
>>   1) A replacement for the previous use of double/uint/int*, now std::vector
>>   2) A replacement for communication using std::vector where resize
>>      flexibility is needed.
>>
>> I think 1, speaks for it self. 2 is where we need to resize any passed vector.
>> This goes for GenericMatrix.getrow, foo.intersection,
>> GenericFunction.comput_vertex_values.
>>
>>> And the work would be to add the extra stuff on the C++ side. The
>>> advantage would be less complex wrapper code and that Garth and I
>>> are capable of handling the complexities on the C++ side.
>> Yes this must be a goal. I agree that the present SWIG situation has grown out
>> of hands.
>>
>>> But what I don't understand is why it would be easier to write a
>>> typemap for SimpleArray than for std::vector. Both of them use
>>> contiguous memory.
>> Yes, but in std::vector it is now way, I suppose, to prevent a vector to
>> delete its data when it goes out of scope. This is necessary in a typical in
>> typemap.
> 
> ok, let's create a very flexible array class that is targeted at
> simple communication between C++ and Python/NumPy. We had a class
> before named SimpleArray. We might call it NumPyArray or PythonArray.
> 

Can we just call it Array? It will be visible in the C++ interface (e.g.
in eval) so it would be good to have a nice name.

> I have created a blueprint:
> 
> https://blueprints.launchpad.net/dolfin/+spec/array-typemaps
> 

I'll add something. I was thinking already about this. With a smart
pointer to the underlying data we should be to devise an elegant memory
model and be able to tell an Array object when it does and doesn't own
the data upon construction, and be able to change during execution.

> We can fill out the details together.
> 
>> I will fix the interface of getrow this evening. I was about to do it
>> yesterday, but instead I got grumpy :) But a good night sleep makes wonders!
> 
> Good! :-)
> 
> Will you make a fast/temporary fix so that we can get ready for a
> release of 0.9.5 and then we can move the PythonArray implementation
> to a future release?
>

The fast fix would be revert back to the

    eval(double*, std::vector<double>&)

interface. No point wasting time on typemaps for std::vector if we're
not going to use them.

Garth

> --
> Anders