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