[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [ESPResSo-users] [ESPResSo-devel] Thoughts from the last coding day
From: |
Rudolf Weeber |
Subject: |
Re: [ESPResSo-users] [ESPResSo-devel] Thoughts from the last coding day |
Date: |
Wed, 1 Jul 2015 09:38:39 +0200 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
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
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- Re: [ESPResSo-users] [ESPResSo-devel] Thoughts from the last coding day,
Rudolf Weeber <=