On Tuesday 01 December 2009 12:03:41 Anders Logg wrote: > On Tue, Dec 01, 2009 at 07:58:12PM +0000, Garth N. Wells wrote: > > Anders Logg wrote: > > > On Tue, Dec 01, 2009 at 07:21:00PM +0000, 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. > > > > > > I'm warming up to the Array class option in which case we don't need > > > to spend more time on fixing typemaps which will be removed anyway. > > > > > > So should the plan then be to use Array as much as possible in the > > > C++ interface, instead of std::vector? We will still use std::vector > > > and other STL types in the implementation but less of it in the user > > > interface. > > > > Perhaps, as long as we don't end up re-implementing all the std::vector > > functionality in Array. > > > > Garth > > I assume we will make it fixed-size which will simplify the > implementation a great deal and differentiate it from std::vector > which has push_back.
>From my point of view, it would be nice to have some sort of resize ability, as more methods and functions could use it, instead of std::vector to pass arguments. For example: GenericMatrix.getrow, foo.intersection. Johan > ok, so let's wait for you to revert the changes to eval() and then see > where we stand. > -- > Anders > _______________________________________________ Mailing list: https://launchpad.net/~dolfin Post to : [email protected] Unsubscribe : https://launchpad.net/~dolfin More help : https://help.launchpad.net/ListHelp
