On Tuesday 01 December 2009 10:51:12 Anders Logg wrote: > On Tue, Dec 01, 2009 at 10:24:02AM -0800, Johan Hake wrote: > > [snip] > > > > > > Sure, I was about to commit this evening but this somewhat turned me > > > > off ;) > > > > > > Are you going to push it? > > > > Tonight! Sorry for the delay. > > You have to convert to our time zone GMT+/-1. :-)
Yeah, sure. I saw Garth almost converted to my time zone, GMT-8, last night :) Johan > -- > Anders > > > > >>> I see your point of having a manageable SWIG interface. It's a > > > >>> strong one. However the lack of compatibility with NumPy still > > > >>> exists. > > > >> > > > >> Maintainability has to be the overriding consideration. > > > > > > > > Yes, I also think this is a strong goal, and I have therefore spent a > > > > lot of time documenting the interface files. > > > > > > The documentation helps me a lot in how to use something, but it hasn't > > > helped (and nor could it) when making changes. > > > > Ok, that is good! > > > > > >> I have spent a > > > >> lot of time trying (and sometimes occasionally succeeding) to make > > > >> just small updates and changes. The time required is not > > > >> sustainable. > > > > > > > > No I agree that std::vector and home made typemaps was a bit over the > > > > top. But the change to std::vector was a decision that was taken in a > > > > thread, with no or few considerations for the SWIG interface. > > > > > > We actually had SWIG/Python in mind when making the change, the idea at > > > the time being that by using std::vector, x would carry information on > > > its dimension which was previously inferred by through the Mesh. I'm > > > not sure that this is valid still in the light of recent changes. > > > > I could have told you. But I probably have to blame my self, as I did not > > put it strong enough when the issue was up. Difficult to follow the pace > > of DOLFIN, with you and Anders being so trigger happy ;) > > > > > >> Also, > > > >> the difficulty of working with the SWIG interface will make it near > > > >> impossible to engage new contributors/maintainers. > > > > > > > > Sure, I just think it was a bit drastic to just remove it instead of > > > > having a discussion on a Blueprint or something. > > > > > > Now that I think about Launchpad, I should have used the fancy new > > > feature to publish a branch along side dolfin/main. > > > > Maybe more of the development of larger features should go into such > > branches? > > > > > >>> NumPy is the natural choice when one want to use contiguous arrays > > > >>> back and forth to Python. I would say that a strong design goal is > > > >>> to have a Python interface that works smoothly with NumPy, which > > > >>> neither std::vector nor std_vector.i do. > > > >> > > > >> Is there a fundamental reason why std::vector and can't NumPy play > > > >> well together? > > > > > > > > Data ownership is not loose enough in std::vector to play well with > > > > NumPy arrays. I think this is the main issue. Ola might add more > > > > here? I think it would be natural for Ola to weight in on this issue > > > > before such a change. > > > > > > > >> Since vectors use contiguous arrays, sounds to me like there > > > >> is scope for adding a numpy.i file to SWIG. > > > > > > > > There are such a file, however it works with (int n, double* data) > > > > and not std::vector. > > > > > > > >> It would be nice to have the NumPy integration, but the typemaps are > > > >> too complicated for us mere mortals. > > > > > > > > Yes, and FE coding is way too complicated for me to know all the > > > > nit-bits in so I am glad there are other people taking care of this. > > > > > > Importantly, there is more than one person active on the FE side. We > > > need more than one person with the ability to work on the SWIG and > > > Python sides. In the absence of able people, we need to make it simple > > > enough that a least a few of us can take care of it. > > > > Yes, I see that. I was just grumpy yesterday :) > > > > > If you ever took a > > > > > > > look into std_vector.i you would see _a lot_ of un-understandable > > > > things too. > > > > > > Yep, but I don't have to look, just like I don't read the STL file > > > 'vector'. I just use it and it works > > > > > :) > > : > > > > I think we had a manageable interface before the std::vector change. > > > > But that's just my 2 cent. > > > > > > For better or worse, we've generally followed a principle of designing > > > what we think is the best C++ interface and then let SWIG and Python > > > follow. It's worked well so far, with a some C++ constructs added and > > > designs modified designs to make the Python side work ultimately being > > > unnecessary and therefore removed. > > > > Yes, and maybe we need to think more of how this could be done in SWIG > > ahead of any larger changes? So the two interfaces could follow each > > other a bit better? > > > > > >>> A better solution, in my point, would either be to stay with > > > >>> double/uint * for the communication of contiguous arrays, or to add > > > >>> a light weight wrapped class in C++ for these data structures. > > > >> > > > >> From the C++ side, I would like to see plain pointers removed from > > > >> the user interface. > > > > > > > > Yes, and I agree. It is preferable from a Python side of view too. > > > > But I would prefer it over a std::vector interface in Python anytime. > > > > There might also be other solutions, which we have not tried. Heck, > > > > for all I know, going with std_vector.i might be the best overall > > > > solution, but I am _really_ not convinced. > > > > > > I'm wondering if std::vector and plain pointers in the interface are > > > the right thing to be wrapping with NumPy. We're generally just > > > exchanging coordinate data and function values in and out. > > > > I see you point. And it might be enough. I just got frustrated working > > with the SWIG vector object in Python as it is not very Pythonic and it > > creates a lot of code for each type we want to wrap, which in turn makes > > the compilation take longer, together with larger binaries. > > > > Feel free to get it working in the other branch. Before we settle on > > whether we go for this solution or we add a SimpleVector class, as > > sketched by Anders, it would be nice to have opinions from Kent and Ola > > too. > > > > > Should it instead be > > > Vectors and Matrices that interface to NumPy? We can access the raw > > > pointers for these objects to create NumPy objects, and we can create > > > Vectors and Matrices from pointers, for example using > > > > > > VecCreateSeqWithArray > > > MatCreateSeqAIJWithArrays > > > > I think that this should be the minimum standard and it works quite > > nicely already I think. > > > > > Whatever the case may be, things have been broken for some days now so > > > we settle on a fix to get back on track. > > > > Yup on to it this evening :) > > > > Johan > > > > _______________________________________________ > > Mailing list: https://launchpad.net/~dolfin > > Post to : [email protected] > > Unsubscribe : https://launchpad.net/~dolfin > > More help : https://help.launchpad.net/ListHelp > _______________________________________________ Mailing list: https://launchpad.net/~dolfin Post to : [email protected] Unsubscribe : https://launchpad.net/~dolfin More help : https://help.launchpad.net/ListHelp
