dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Tue, Dec 01, 2009 at 11:58:02AM -0800, Johan Hake wrote:
> On Tuesday 01 December 2009 11:51:20 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.
> > 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).
>
> Having an Array class do make sense as DOLFIN is a two language library.
>
> > > >>> 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.
>
> ???

I meant C++ programmers vs Python programmers. Not C++ programmers vs
SWIG programmers. ;-)

--
Anders

Attachment: signature.asc
Description: Digital signature