dolfin team mailing list archive

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

Johan Hake wrote:
> On Tuesday 01 December 2009 12:03:41 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.
> 
> From my point of view, it would be nice to have some sort of resize ability, 
> as more methods and functions could use it, instead of std::vector to pass 
> arguments. For example: GenericMatrix.getrow, foo.intersection.
>

A simple resize would be easy, i.e. the entire vector is cleared if a
change in length is needed. A vector which can grow/shrink gets while
preserving data is more complicated and I don't think that we need it.

Garth

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