On Tuesday 01 December 2009 11:48:32 Garth N. Wells wrote: > Johan Hake wrote: > > On Tuesday 01 December 2009 11:21:00 Garth N. Wells wrote: > >> 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. > > > > Isn't the amount of files that are touched with option 1 much larger (all > > cpp/demos)? > > Yes, but it's easy. I can just selectively revert files.
Fine. > But if you do the changes feel free. I can take a look at it this > > > evening if there's something left to do. The new expression.py should at > > least still be working I think, only compile_expressions.py needs an > > update. > > Yes. > > Perhaps you could push your std:vector work to a branch so we have a > record of it and don't go re-inventing the wheel in the future. Sure. I make it working and then push it to such a branch. Johan _______________________________________________ Mailing list: https://launchpad.net/~dolfin Post to : [email protected] Unsubscribe : https://launchpad.net/~dolfin More help : https://help.launchpad.net/ListHelp
