[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [ESPResSo-users] [ESPResSo-devel] Thoughts from the last coding day

From: Florian Weik
Subject: Re: [ESPResSo-users] [ESPResSo-devel] Thoughts from the last coding day
Date: Tue, 30 Jun 2015 16:49:27 +0200

Rudolf and me also discussed your first point and have also the opinion that a change of the constructor of ParticleHandle is a viable way to deal with that. You would have to add the position as mandatory parameter to the constructor, that is the only property particles in Espresso have to have.
Regarding the use of Cython this is manly used to access C functionality, which can't be done in plain python. I would not know of any part where there are actually larger amounts of new functionality written in Cython. I agree with you that lots of stuff is not actually performance critical and should
be done in plain python to improve readability and ease of development (duct typing is what makes python great...). 
In the larger picture Cython might not be the ideal choice for Espresso. Or at least it would be if we had a decent C++ class interface to the core, which we don't.
I think boost::python, which would be more suitable for a c++ code, was ruled out because we did not have a decent interface and people felt that they should
start with the python interface instead of giving the core a clear and modern structure first.
Also with Cython you have in principle the possibility to call Cython code from c++, which might be handy. But we do not do that at the moment and I don't see
any concrete use case for that either, but who knows....
So to summarize, we need some way to glue the parts together. As far as I can see we have almost exclusively glue code so far, which has to be Cython.
Cython was a design decision made in the past and can't be reverted easily. While Cython is here to stay, we should limit it's use to cases where it is necessary because
it interfaces with the c++ core or where it has a proven significant performance advantage over python/numpy and that part is relevant to overall performance.
From a practical point of view, I am pretty confident that people will try python first and only use Cython if that does not work or is slow. Just due to ease of development.

Best regards,

On Tue, Jun 30, 2015 at 4:11 PM, Gary Davies <address@hidden> wrote:
Dear All

I wanted to talk about this at the last espresso meeting, but unfortunately I was away doing my PhD exam. 

I thought maybe I'd highlight some of my thoughts about what I saw in the python interface that we can discuss over email before the next coding day and perhaps briefly at the next coding day. 

I implemented an iterator/generator function that allows the user to do something like: 

for p in S.part:
   bla bla bla

However, I haven't yet pushed the changes because I don't feel that it really does what we would ideally like it to do. 

Issue 1) It's possible to create a particle handle without creating a physical particle in the system. Since S.part is a (somewhat) a list of particle handles, this is troublesome because in the iterator you loop through a list of particle handles rather than particles. Therefore, if you request a property from the particle handle and the particle does not exist, an exception is thrown. 

I personally don't see this as desirable behaviour, but I want to hear arguments for and against. 

My suggestion is to change the constructor of the ParticleHandle class such that it must accept the relevant parameters in order to successfully initialise a particle. Interesting to hear your thoughts on this. 

Issue 2) The potential over-use of Cython. 

In my opinion, one of the big attractions of using Python as the espresso interface is the increased readability and simplicity of python code. Cython significantly reduces this readability and simplicity, IMO. However, it seems that everything is written in Cython by default without regard for whether it actually speeds up the code significantly. Ideally we should be writing everything in native python and only cythonising the performance bottlenecks. 

Is there a reason that everything is by default cython and not native python? Perhaps I have misunderstood something fundamental to the python interface here. 

That's about all I can remember for now. 

Interested to hear your opinions on the above 2 issues. 

Best wishes, Gary

Florian Weik

++49 157 85939252

reply via email to

[Prev in Thread] Current Thread [Next in Thread]