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
signature.asc
Description: Digital signature
_______________________________________________ Mailing list: https://launchpad.net/~dolfin Post to : [email protected] Unsubscribe : https://launchpad.net/~dolfin More help : https://help.launchpad.net/ListHelp
