dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

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.

I was thinking of having it in addition to std::vector.

> > 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.

--
Anders

Attachment: signature.asc
Description: Digital signature