dolfin team mailing list archive

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

Anders Logg wrote:
> On Tue, Dec 01, 2009 at 07:58:12PM +0000, Garth N. Wells wrote:
>>
>> Anders Logg wrote:
>>> On Tue, Dec 01, 2009 at 07:21:00PM +0000, Garth N. Wells wrote:
>>>> Johan Hake wrote:
>>>>> On Tuesday 01 December 2009 11:06:43 you 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.
>>>>> Agree.
>>>>>
>>>>>>> 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 fancy.
>>>>>
>>>>>>> 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.
>>>>> Fell free to make this change, I have a fool proof plan for the other
>>>>> temporary fix though. No new typemaps, just reusing old ones.
>>>>>
>>>> OK, we need to make a decision.
>>>>
>>>> Option 1: Revert changes to eval.
>>>>
>>>> Option 2: Get SWIG working with the eval(std::vector<double>&, const
>>>> std::vector<double>&) interface.
>>>>
>>>> What's it going to be? I'm inclined to Option 1 since it requires no
>>>> work and it's been well tested.
>>> I'm warming up to the Array class option in which case we don't need
>>> to spend more time on fixing typemaps which will be removed anyway.
>>>
>>> So should the plan then be to use Array as much as possible in the
>>> C++ interface, instead of std::vector? We will still use std::vector
>>> and other STL types in the implementation but less of it in the user
>>> interface.
>>>
>> Perhaps, as long as we don't end up re-implementing all the std::vector
>> functionality in Array.
>>
>> Garth
> 
> I assume we will make it fixed-size which will simplify the
> implementation a great deal and differentiate it from std::vector
> which has push_back.
> 

Fixed on the C++ side. It should have a function to indicate a change in
size. That way, we can have this process

1. An Array is received and turned into a NumPy
2. Length of NumPy array changes on the Python side
3. Array is 'informed' of the new length when sent back to C++

This change in length on the Python side is something we can't handle at
the moment as far as I understand.

Garth

> ok, so let's wait for you to revert the changes to eval() and then see
> where we stand.
> 
> --
> Anders