Record particle RMS displacement from initial (to check HS fluid decorrelation)

[kjs73]

Adds action for recoding scalar time series. Time series consists of RMS displacement of a particle from its initial position, averaged over all particles. Probably this is only helpful for "non-periodic distances".

This PR depends on PR #19.

[kjs73]

Yes, that can be, sorry. This is according to the convention where the arguments of the constructor are followed by , and then they initialise the corresponding members of the class, which have the same name, but without . But we can homogenise that, I guess.

[kjs73]

On the other hand: is not almost everything somehow member of a class? I am not sure if we gain too much by making class members' names more complicated.

One reason to to have a trailing underscore would be to have a get function that is not called getvariable() but just variable(), and for that it is nice to have variable be called variable. But if we decided to use get_variable() anyway, maybe this is not needed?

[js850]

I prefer get_variable() and set_variable() in most instances. It has a verb in the name :)

Also, I think variable is more standard than variable. We've been using the former, so let's keep that as the default. On 12 Jul 2014 08:53, "kjs73" notifications@github.com wrote:

On the other hand: is not almost everything somehow member of a class? I am not sure if we gain too much by making class members' names more complicated.

One reason to to have a trailing underscore would be to have a get function that is not called getvariable() but just variable(), and for that it is nice to have variable be called variable. But if we decided to use get_variable() anyway, maybe this is not needed?

Reply to this email directly or view it on GitHub https://github.com/pele-python/mcpele/pull/22#issuecomment-48805211.

[js850]

I think _variable is more standard

actually, this is frowned on because lots of words reserved by the compiler start with underscore and you can easily stumble upon conflicts. It seems the most common is m_variable. Maybe the postfix is better variable_?

[kjs73]

Yes, starting an identifier with underscore only somehow works recently, I think.

What do you think about not having any (leading or trailing) underscore or special features in the name?

The there will be compiler errors if we try to access a private variable outside. For the public ones, it does not matter. And we are using get_member(), so there is also no function name conflict.

[js850]

personally I like emphasising which are class members and which aren’t.

python forces you to do self.variable if you want to access the member. c++ doesn’t force that, but I think it’s a good idea to emphasise it.

I think it comes down to preference. we should decide on one and stick with it. I would vote for a variable_. julian votes for variable, stefano, what do you think?

On 12 Jul 2014, at 09:55, kjs73 notifications@github.com wrote:

Yes, starting an identifier with underscore only somehow works recently, I think.

What do you think about not having any underscore or special features in the name?

The there will be compiler errors if we try to access a private variable outside. For the public ones, it does not matter. And we are using get_member(), so there is also no function name conflict.

— Reply to this email directly or view it on GitHub.

[smcantab]

So far we have used used variable almost everywhere, which is the most pythonic notation because it recalls the self. in front of a class member. However, since in c++ the underscore used to denote information for the compiler only, we can switch to using variable or m_variable. I like knowing what is a class member and what isn't, especially when the code has been written by someone else.

Ultimately these are python libraries that we are writing, so I like the idea of having a similar style even across languages when it comes to naming. So maybe m_variable is the most pythonic? And also clearest? This notation could also be extended to functions that are meant to be private and not to be called from outside the class, just as we do in python.

Stefano On 12 Jul 2014 10:04, "Jacob Stevenson" notifications@github.com wrote:

personally I like emphasising which are class members and which aren’t.

python forces you to do self.variable if you want to access the member. c++ doesn’t force that, but I think it’s a good idea to emphasise it.

I think it comes down to preference. we should decide on one and stick with it. I would vote for a variable_. julian votes for variable, stefano, what do you think?

On 12 Jul 2014, at 09:55, kjs73 notifications@github.com wrote:

Yes, starting an identifier with underscore only somehow works recently, I think.

What do you think about not having any underscore or special features in the name?

The there will be compiler errors if we try to access a private variable outside. For the public ones, it does not matter. And we are using get_member(), so there is also no function name conflict.

— Reply to this email directly or view it on GitHub.

— Reply to this email directly or view it on GitHub https://github.com/pele-python/mcpele/pull/22#issuecomment-48806363.

[kjs73]

OK, summarising we have to decide between mvariable and variable ? Or is it already decided? I will abstain from voting :)

On 12 July 2014 11:05, smcantab notifications@github.com wrote:

So far we have used used variable almost everywhere, which is the most pythonic notation because it recalls the self. in front of a class member. However, since in c++ the underscore used to denote information for the compiler only, we can switch to using variable or m_variable. I like knowing what is a class member and what isn't, especially when the code has been written by someone else.

Ultimately these are python libraries that we are writing, so I like the idea of having a similar style even across languages when it comes to naming. So maybe m_variable is the most pythonic? And also clearest? This notation could also be extended to functions that are meant to be private and not to be called from outside the class, just as we do in python.

Stefano On 12 Jul 2014 10:04, "Jacob Stevenson" notifications@github.com wrote:

personally I like emphasising which are class members and which aren’t.

python forces you to do self.variable if you want to access the member. c++ doesn’t force that, but I think it’s a good idea to emphasise it.

I think it comes down to preference. we should decide on one and stick with it. I would vote for a variable_. julian votes for variable, stefano, what do you think?

On 12 Jul 2014, at 09:55, kjs73 notifications@github.com wrote:

Yes, starting an identifier with underscore only somehow works recently, I think.

What do you think about not having any underscore or special features in the name?

The there will be compiler errors if we try to access a private variable outside. For the public ones, it does not matter. And we are using get_member(), so there is also no function name conflict.

— Reply to this email directly or view it on GitHub.

— Reply to this email directly or view it on GitHub https://github.com/pele-python/mcpele/pull/22#issuecomment-48806363.

— Reply to this email directly or view it on GitHub https://github.com/pele-python/mcpele/pull/22#issuecomment-48807472.

[smcantab]

+1 for mvariable for members. I don't like variable, I feel like it should a prefix that tells me what's the namescope of the variable. The c++ natural way would be to put this-> in front of each member but that's a lot of typing and I think it's really ugly.

Here there is some discussion on name convention:

http://stackoverflow.com/questions/1228161/why-use-prefixes-on-member-variables-in-c-classes

One guys suggests the following notation:

• m for members
• c for constants/readonlys
• p for pointer (and pp for pointer to pointer)
• v for volatile
• s for static
• i for indexes and iterators
• e for events

On Mon, Jul 14, 2014 at 9:30 AM, kjs73 notifications@github.com wrote:

OK, summarising we have to decide between mvariable and variable ? Or is it already decided? I will abstain from voting :)

On 12 July 2014 11:05, smcantab notifications@github.com wrote:

So far we have used used variable almost everywhere, which is the most pythonic notation because it recalls the self. in front of a class member. However, since in c++ the underscore used to denote information for the compiler only, we can switch to using variable or m_variable. I like knowing what is a class member and what isn't, especially when the code has been written by someone else.

Ultimately these are python libraries that we are writing, so I like the idea of having a similar style even across languages when it comes to naming. So maybe m_variable is the most pythonic? And also clearest? This notation could also be extended to functions that are meant to be private and not to be called from outside the class, just as we do in python.

Stefano On 12 Jul 2014 10:04, "Jacob Stevenson" notifications@github.com wrote:

personally I like emphasising which are class members and which aren’t.

python forces you to do self.variable if you want to access the member. c++ doesn’t force that, but I think it’s a good idea to emphasise it.

I think it comes down to preference. we should decide on one and stick with it. I would vote for a variable_. julian votes for variable, stefano, what do you think?

On 12 Jul 2014, at 09:55, kjs73 notifications@github.com wrote:

Yes, starting an identifier with underscore only somehow works recently, I think.

What do you think about not having any underscore or special features in the name?

The there will be compiler errors if we try to access a private variable outside. For the public ones, it does not matter. And we are using get_member(), so there is also no function name conflict.

— Reply to this email directly or view it on GitHub.

— Reply to this email directly or view it on GitHub https://github.com/pele-python/mcpele/pull/22#issuecomment-48806363.

— Reply to this email directly or view it on GitHub https://github.com/pele-python/mcpele/pull/22#issuecomment-48807472.

— Reply to this email directly or view it on GitHub https://github.com/pele-python/mcpele/pull/22#issuecomment-48876011.

[js850]

I'm OK with m_variable for member variables. Lets try it on a few classes and see how we like it.

[kjs73]

The m_ convention is now followed in the c++ files involved in this pull request.