dolfin team mailing list archive

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

Anders Logg wrote:
> On Tue, Dec 01, 2009 at 07:16:36PM +0000, Garth N. Wells wrote:
>>
>> Anders Logg wrote:
>>> On Tue, Dec 01, 2009 at 07:06:43PM +0000, Garth N. Wells wrote:
>>>> 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 thought we should not name it Array so as to not encourage use of
>>> it, or do you suggest using it instead of std::vector.
>>>
>> Yes.
>>
>>> I was thinking of having it in addition to std::vector.
>>>
>> We would have multiple versions of eval functions if we support
>> std::vector and Array. It wouldn't be clear to a user which to use.
>> Also, we could avoid some copying of data if we use Array since an Array
>> could be initialised with a pointer to some data, whereas a vector can't.
> 
> It makes sense, but I'll need some more convincing. We have an Array
> class before. The reason I added it then was that we wanted a
> nice-looking interface with minimal visibility of other libraries.

A new Array would have a different purpose to what we had before. The
old one wrapped std::vector. The purpose of a new Array class is a
safe(ish) object which can be initialised to point to an array, which is
what we need to interface with NumPy.

> We also had a List class for a linked list etc.
> 
> But having an Array class does make some sense considering we have
> Vector and Matrix classes (that happen to be implemented using for
> example PETSc).
> 
>>>>> 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.
>>> Sounds good.
>>>
>>>>> 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.
>>> Good point, but if it's possible to fix with moderate work I suggest
>>> we (Johan...) fix it before the release.
>>>
>>> This might be the last release in a long time with major interface
>>> changes to the Expression/Function classes and then it would be good
>>> to have it all in place at once.
>>>
>> You mean that you want a new Array class in place? I don't think that is
>> feasible in a short time.
>>
>> Garth
> 
> No, not if we go for that option. Then it doesn't really matter about
> the real* vs std::vector thing.
> 
> But the Python interface will remain unchanged which is good. C++
> users are a bit more hardcore and can live with the changes.
> 

OK.

Garth

> --
> Anders