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.
A new Array would have a different purpose to what we had before. The old one wrapped std::vector. The purpose of a new Array class is a safe(ish) object which can be initialised to point to an array, which is what we need to interface with NumPy. > 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). > >>>>> 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. > OK. Garth > -- > Anders _______________________________________________ Mailing list: https://launchpad.net/~dolfin Post to : [email protected] Unsubscribe : https://launchpad.net/~dolfin More help : https://help.launchpad.net/ListHelp
