How the new move/rotate should behave

[OrtnerMichael]

Goals

• Move objects (absolute/relative to existing position)
• create object path (absolute/relative to existing position)
• Merge/overwrite/append existing paths (starting at position of choice, automatically pad old path if needed)
  • Apply one operation to a whole path
  • Apply one operation to a single path element of choice

#433

WIP

[Alexboiboi]

I will just present the way I see it for now for the move method, below. The same idea applies to the rotate methods.

old method signature:

def move(self, displacement, start=-1, increment=False): -> self

new method signature:

def move(self, displacement, start=None, repeats=None): -> self

• case 1: displacement is a 1D array
  • case 1a: start=None, repeats=None -> move object or entire path if it exists
  • case 1b: start=i, repeats=None -> move position at index i
  • case 1c: start=None, repeats=j -> repeats creates a (j,3) array -> append new positions
  • case 1d: start=i, repeats=j -> repeats creates a (j,3) array -> move positions starting at index i
• case 2: displacement is a 2D array of shape (k,3)
  • case 2a->start=None, repeats=None -> append new positions
  • case 2b: start=i, repeats=None -> move positions starting at index i
  • case 2c: start=None, repeats=j -> repeats creates a (j*k,3) array -> append new positions
  • case 2d: start=i, repeats=j -> repeats creates a (j*k,3) array -> move positions starting at index i

Regarding absolute positioning of a single index I don't really see the use of the move method. I would just do:

src.position[i] = [x,y,z]

@OrtnerMichael What do you think

[OrtnerMichael]

I think we need very clean clear pure short self-consistent statements what the kwargs do. I propose something like:

Start Statement
start=i applies operation starting at the i'th path index. start=None applies operation to the whole path.

Repeat Statement:
repeat=x should apply an operation subsequently x times.

Absolute Statement
If absolute=False then operations are applied on top of existing positions (move_by), else (move_to)

---

The absolute kwarg is needed to append absolute positions which could otherwise only be achieved through something like
s.move(x-s.position). Its a useful functionality, e.g., when you have an algorithm that computes new positions that you then want to append to the existing path (e.g. motion dynamics that will come with getBT)

---

This repeat statement is in contradiction to 1d.

s = magpy.Sensor()
s.move((0,0,1), start=None, repeat=2)
print(s.position)

We should get [(0,0,0), (0,0,1), (0,0,2)] in accordance with case 1c and the repeat statement.

But what happens we we do

s = magpy.Sensor(position=[(0,0,1), (0,0,2), (0,0,3)])
s.move((0,0,1), start=1, repeat=2)
print(s.position)

Do we get [(0,0,1), (0,0,4), (0,0,3)] or [(0,0,1), (0,0,3), (0,0,4)].
I think the first should happen in accordance with the repeat statement - which is contradictory to 1d.

Is the 1d behavior necessary ? It could be achieved with s.move([(0,0,1)]*2, start=1) using 2b logic.
Should the repeat statement be reformulated ?

THIS POST IS STILL WIP

[Alexboiboi]

the repeat statement always transforms a 1D array into a 2D one, see next post for the expected outputs

[Alexboiboi]

Lets go through with examples and fill them with what should be expected and always start with:

still WIP of course

• Case 1a

import magpylib as magpy
s = magpy.Sensor(position=[(0,0,0),(0,0,1),(0,0,2)])
s.move((0,0,10), start=None, repeat=None)
print(s.position)
# [(0,0,10),(0,0,11),(0,0,12)]

• Case 1b

import magpylib as magpy
s = magpy.Sensor(position=[(0,0,0),(0,0,1),(0,0,2)])
s.move((0,0,10), start=1, repeat=None)
print(s.position)
# [(0,0,0),(0,0,11),(0,0,12)]

• Case 1c

import magpylib as magpy
s = magpy.Sensor(position=[(0,0,0),(0,0,1),(0,0,2)])
s.move((0,0,10), start=None, repeat=2)
print(s.position)
# [(0,0,0),(0,0,1),(0,0,2),(0,0,12),(0,0,22)]

• Case 1d

import magpylib as magpy
s = magpy.Sensor(position=[(0,0,0),(0,0,1),(0,0,2)])
s.move((0,0,10), start=1, repeat=2)
print(s.position)
# [(0,0,0),(0,0,11),(0,0,22)]

• Case 2a

import magpylib as magpy
s = magpy.Sensor(position=[(0,0,0),(0,0,1),(0,0,2)])
s.move([(0,0,10),(0,0,100)], start=None, repeat=None)
print(s.position)
# [(0,0,0),(0,0,1),(0,0,2),(0,0,12),(0,0,102)]

• Case 2b

import magpylib as magpy
s = magpy.Sensor(position=[(0,0,0),(0,0,1),(0,0,2)])
s.move([(0,0,10),(0,0,100)], start=1, repeat=None)
print(s.position)
# [(0,0,0),(0,0,11),(0,0,102)]

• Case 2c

import magpylib as magpy
s = magpy.Sensor(position=[(0,0,0),(0,0,1),(0,0,2)])
s.move([(0,0,10),(0,0,100)], start=None, repeat=2)
print(s.position)
# [(0,0,0),(0,0,1),(0,0,2),(0,0,12),(0,0,102),(0,0,12),(0,0,102)]

• Case 2d

import magpylib as magpy
s = magpy.Sensor(position=[(0,0,0),(0,0,1),(0,0,2)])
s.move([(0,0,10),(0,0,100)], start=1, repeat=2)
print(s.position)
#  [(0,0,0),(0,0,11),(0,0,102),(0,0,12),(0,0,102)]

[OrtnerMichael]

Your Repeat statement would be
repeat=n tiles the input n times and interprets them as increments of each other

---

Your current 2d is not consistent with 1d I think

s.move([(0,0,10),(0,0,100)], start=1, repeat=2) should tile the input up to (0,0,10),(0,0,100),(0,0,10),(0,0,100) and then interpret it incremental which would lead to # [(0,0,0),(0,0,11),(0,0,112),(0,0,122),(0,0,222)]

---

Generally I don't like this way of interpreting repeat because

1. There is almost no benefit over the previous increment argument
2. The usefulness is limited to the case where you want to fast-create a path ... like s.rotate(1, 'z', repeat=360).
3. Its even more difficult to understand what this operation does than before.
4. The much simpler statement in my post above (repeated operation) provides the same fast-create feature.

Based on this, is questionable if this kwarg and feature is necessary at all ?

1. I'm using it regularly when I want to quickly check/demonstrate something - but never for purposeful computation because then I always also need to have the angles/positions at disposal
2. The fast-create could be realized by generating a path as [(0,0,i) for i in range(10)] which would be much easier to understand for everyone else. For angles is even easier np.linspace(0,360,720)
3. Is there any other use to this ? - because if not I propose we remove this kwarg completely under the rule no useless features :)

[Alexboiboi]

With the obvious complexity arising, I agree that the simplest would be to just remove the increment parameter ;)

btw the [(0,0,i) for i in range(10)] method is only that simple for integer steps. The more general way is thennp.linspace((0,0,0), (0,0,10), 10 , endpoint=False) (endpoint is True by default)

[OrtnerMichael]

Temporary conclusion we can both agree on: increment/ repeat goes out

[OrtnerMichael]

Revised proposal

Input Statement
If the input is a scalar the operation is applied to the whole path. If the input is a vector, it is merged with the existing path.

Start Statement
start=i applies an operation starting at the i'th path index. start=None applies an operation to the whole path.

Absolute Statement
If absolute=False then transformations are applied on to existing positions/orientations. If absolute=True position/orientation are set to input values.

---

Case 1.1

s = magpy.Sensor(position=(0,0,1))
s.move((0,0,10), start=None, absolute=False)
print(s.position)
# (0,0,11)

Usefulness: 3/3

• Fundamental magpylib idea of moving objects around

---

Case 1.2

s = magpy.Sensor(position=[(0,0,1),(0,0,2),(0,0,3)])
s.move((0,0,10), start=None, absolute=False)
print(s.position)
# [(0,0,11),(0,0,12),(0,0,13)]

Usefulness 2/3

• now whole paths can be moved around.
• v3: the last path position would be modified was that more useful ? This can now be done with s.move(x, start=-1).

---

Case 1.3

s = magpy.Sensor(position=(0,0,1))
s.move((0,0,10), start=1, absolute=False)
print(s.position)
# (0,0,1) + Warning that nothing happens  OR  pad path to start

Usefulness: 0/3

---

Case 1.4

s = magpy.Sensor(position=[(0,0,1),(0,0,2),(0,0,3)])
s.move((0,0,10), start=1, absolute=False)
print(s.position)
# [(0,0,1),(0,0,12),(0,0,13)]

Usefulness 1/3

• consistent but probably useless

---

Case 1.5

s = magpy.Sensor(position=(0,0,1))
s.move((0,0,10), start=None, absolute=True)
print(s.position)
# (0,0,10)

Usefulness: 3/3

• setting absolute object positions
• alternatives would be annoying like s.move(x-s.position)

---

Case 1.6

s = magpy.Sensor(position=[(0,0,1),(0,0,2),(0,0,3)])
s.move((0,0,10), start=None, absolute=True)
print(s.position)
# [(0,0,10),(0,0,10),(0,0,10)]

Usefulness 1/3

• consistent but probably useless

---

Case 1.7

s = magpy.Sensor(position=(0,0,1))
s.move((0,0,10), start=1, absolute=True)
print(s.position)
# (0,0,1) + Warning that nothing happens  OR  pad path to start

Usefulness: 0/3 (same as case 1.3)

---

Case 1.8

s = magpy.Sensor(position=[(0,0,1),(0,0,2),(0,0,3)])
s.move((0,0,10), start=1, absolute=True)
print(s.position)
# [(0,0,1),(0,0,10),(0,0,10)]

Usefulness 1/3

• consistent but probably useless

---

Case 2.1

s = magpy.Sensor(position=(0,0,1))
s.move([(0,0,10),(0,0,11),(0,0,12)], start=None, absolute=False)
print(s.position)
# [(0,0,1),(0,0,11),(0,0,12),(0,0,13)]

Usefulness: 3/3

• Fundamental relative path-appending functionality
• v3 would always overwrite the last existing path position which is annoying

---

Case 2.2

s = magpy.Sensor(position=[(0,0,1),(0,0,2),(0,0,3)])
s.move([(0,0,10),(0,0,11),(0,0,12)], start=None, absolute=False)
print(s.position)
# [(0,0,1),(0,0,2),(0,0,3),(0,0,13),(0,0,14),(0,0,15)]

Usefulness 3/3

• Fundamental relative path-appending functionality

---

Case 2.3

s = magpy.Sensor(position=(0,0,1))
s.move([(0,0,10),(0,0,11),(0,0,12)], start=2, absolute=False)
print(s.position)
# [(0,0,1), (0,0,11), (0,0,12), (0,0,13)] OR padding ?

Usefulness: 1/3

• consistent but useless
• but why would you define a start value when you have a scalar path ?

---

Case 2.4

s = magpy.Sensor(position=[(0,0,1),(0,0,2),(0,0,3)])
s.move([(0,0,10),(0,0,11),(0,0,12)], start=1, absolute=False)
print(s.position)
# [(0,0,1),(0,0,12),(0,0,14),(0,0,15)]

Usefulness 3/3

• path merging and padding when input exceeds existing path

---

Case 2.5

s = magpy.Sensor(position=(0,0,1))
s.move([(0,0,10),(0,0,11),(0,0,12)], start=None, absolute=True)
print(s.position)
# [(0,0,1), (0,0,10), (0,0,11), (0,0,12)]

Usefulness: 3/3

• appending an absolute path
• alternatives would be annoying like s.move(x-s.position)

---

Case 2.6

s = magpy.Sensor(position=[(0,0,1),(0,0,2),(0,0,3)])
s.move([(0,0,10),(0,0,11),(0,0,12)], start=None, absolute=True)
print(s.position)
# [(0,0,1), (0,0,2), (0,0,3), (0,0,10), (0,0,11), (0,0,12)]

Usefulness 3/3 (same as case 2.5)

• appending an absolute path
• alternatives would be annoying like s.move(x-s.position)

---

Case 2.7

s = magpy.Sensor(position=(0,0,1))
s.move([(0,0,10),(0,0,11),(0,0,12)], start=1, absolute=True)
print(s.position)
# [(0,0,1), (0,0,10), (0,0,11), (0,0,12)]

Usefulness: 2/3

• consistent and sometimes useful (e.g. sweep edge cases)
• The start value is ignored because it is larger than the existing path

---

Case 2.8

s = magpy.Sensor(position=[(0,0,1),(0,0,2),(0,0,3)])
s.move([(0,0,10),(0,0,11),(0,0,12)], start=1, absolute=True)
print(s.position)
# [(0,0,1),(0,0,10),(0,0,11),(0,0,12)]

Usefulness 3/3

• path overwriting

what do you think @Alexboiboi ?

[OrtnerMichael]

Conclusion 1: Take increment out and do not replace - its not a worthy feature
Conclusion 2: The absolute is cool but not critical for now - add now or later
Conclusion 3: The start='auto' (fullpath if input is scalar, append/merge if input is vector) is better than the current start=-1 because

• It adds some features like whole path movement without additional syntax/kwargs
• It provides full previous functionality
• It brings all most important features to the default level (-1 and append)
• It is easier to understand/describe the behavior than previous -1 default
  Conclusion 4: Padding up a path when start=x with x>pathlength rather than just appending
  Conclusion 5: DO NOT auto-pad orientation when s.position=x - it creates some strange behavior

This all goes to issue XXX