Norm of a state

[zhanglw0521]

I am a little bit lost about the norm of a DecoratedParticle.

My memory was that an AbstractState should not have a norm, but now it has one which seems to be a weighted norm of all its elements (cf here).

For instance, if we have two States R1 = State(rr = SVector{3}([1,0,0]), be = false) and R2 = State(rr = SVector{3}([1,0,0]), be = true), those bool values are also counted when we evaluate norm(R) (i.e., they return 1 and $\sqrt2$ respectively, which means that Bools are viewed as 0 and 1 in this case). If we have some fields like charge, then the norm of this State also counts the charges. This is a little bit strange to me...

[cortner]

In the past when I defined norm on a State I only counted the floats but not the integers or other counting variables. So in the case above you would get 1 both times. If that doesn't happen right now then I would consider this a bug. (though in truth it is a matter of convention)

[zhanglw0521]

It makes sense to me if norm only counts floats. But what I get from the above example is indeed 1 and 1,41421, which gives a smell of a bug. In addition, in the above example, rr is a SVector of Int, which should not be counted if the code counts only floats?

[cortner]

both correct. I don't remember why we changed it. (or maybe we didn't and this was a bug in the past as well?)

[cortner]

I now wonder whether any arithmetic should act on all number types including integers, bools etc. At least by default. I'm not sure really, just wondering out loud ....

[zhanglw0521]

It is actually not so clear to me how some arithmetics mean for an abstract state, for instance, what should be the output of "Bool + Bool". I am thinking that could we somewhat leave the definition of arithmetics (apart from those obvious arithmetics for positions) on State to the users (maybe even including norm) when it is needed, and we document this somewhere in this package (for example, such that users can see this part when they try ?State).

What this basically results in is that when a user tries to do one arithmetic of State (that would mean that they have some expected outcome in mind), they will find that it is by default not defined (error shows), but then when they try ?State they know they could define something themself...

[cortner]

I think I will make the following convention : arithmetic is defined on all number-like types (to be documented) and if one uses a number-like type that one doesn't want arithmetic performed on (e.g. Z::Integer for atomic number) then such types must be wrapped and they will then be treated as categorical.

[cortner]

For booleans, it is less clear to me. Maybe they need to be treated as special.

[zhanglw0521]

That makes sense to me. Maybe should I rename this issue to something like "arithmetic of States" (given that if some types of a State can be wrapped and treated as categorical, the original norm issue may no longer exist)?

[cortner]

Possibly. The arithmetic anyhow needs to be worked out.