dolfin team mailing list archive

[Johan Hake <johan.hake@xxxxxxxxx>]

On Tuesday 01 December 2009 11:48:32 Garth N. Wells wrote:
> Johan Hake wrote:
> > On Tuesday 01 December 2009 11:21:00 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.
> >
> > Isn't the amount of files that are touched with option 1 much larger (all
> > cpp/demos)?
> 
> Yes, but it's easy. I can just selectively revert files.

Fine.

> But if you do the changes feel free. I can take a look at it this
> 
> > evening if there's something left to do. The new expression.py should at
> > least still be working I think, only compile_expressions.py needs an
> > update.
> 
> Yes.
> 
> Perhaps you could push your std:vector work to a branch so we have a
> record of it and don't go re-inventing the wheel in the future.

Sure. I make it working and then push it to such a branch. 

Johan