Anders Logg wrote: > On Tue, Dec 01, 2009 at 08:08:54PM +0000, Garth N. Wells wrote: >> >> 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. >>> >> Fixed on the C++ side. > > What do you mean? Did you implement this already? >
No, I haven't implemented anything. Garth > -- > Anders > > >> It should have a function to indicate a change in >> size. That way, we can have this process >> >> 1. An Array is received and turned into a NumPy >> 2. Length of NumPy array changes on the Python side >> 3. Array is 'informed' of the new length when sent back to C++ >> >> This change in length on the Python side is something we can't handle at >> the moment as far as I understand. >> >> Garth >> >>> ok, so let's wait for you to revert the changes to eval() and then see >>> where we stand. >>> >> _______________________________________________ Mailing list: https://launchpad.net/~dolfin Post to : [email protected] Unsubscribe : https://launchpad.net/~dolfin More help : https://help.launchpad.net/ListHelp
