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

[Rudolf Weeber]

Hi,
On Tue, Jun 30, 2015 at 04:11:48PM +0200, Gary Davies wrote:
> 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.
While I'm not sure, I find that necessary, I'm also not opposed to it.
What is important is that one cannot shoot oneself in the foot. 
This is already the case, because accessing a particle property of an 
un-initialized particles raises an exception.


With regards to iterators and slicing, I would find the following reasonable:
for p in S.part
  iterates over all existing particles

S.part[:].v  
  returns an N by 3 array 

S.part[:].v =array((0,0,0)) 
  sets the velocity of all particles to this vector
S.part[:].v =N-by-3-array 
  sets the velocities of all N particles according to the rows in the array


S.part[0:10].v
  Returns a 10x3 array for particles with ids from 0<=i<10.
  If, for one of the ids in the range, no particle exists, raise exception


S.part[0:10].v=...
  Set velocites in the respective range. Raise exception if one of the 
particles doesn't exist

S.part[:10] should refer to all particles with id <10
S.part[10:] should refer to all paritlces with id >=10 






> 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.
I agree that cdef-classes should only be used, when needed.
I'd find it confusing, however, to distribute topically related code over two 
files using python vs. cython as criterion.
For the ParticleHandles, Cython is necessary, because they have a cdef'ed 
member variable, Which is only allowed for cdef-classes.
The same goes for actors: In those cases, where an interface class actually 
instantiates the C++-class, it needs to keep a pointer to this instance as a 
class member. As cdef-classes cannot inherit from pure Python classes, the 
entire actor class hierarchy has to be cdef-classes (There's a pull request for 
that (341)).

Regards, Rudolf