Index conventions and Reference Frame Unit Vector access

[Luke]

There are two issues I would like to discuss in PyDy. The first is
the convention for 0 based indexing vs. 1 based indexing. The second
issue is how to access the UnitVectors associated with a
ReferenceFrame object.

Throughout pretty much every text I've seen in a dynamics class,
indexing starts at 1. This is also the convention in languages like
Fortran (although you can use 0 indexing if you want) and Matlab. In
contrast, C based languages (i.e. Python) generally index lists,
arrays, and other such things starting at 0. The issue arises when
you want to use symbols that are subscripted starting at 1, yet your
environment works with 0 based indexing. This is currently the case
in PyDy. As an example:
>>> q, qd = N.declare_coords('q', 5)
>>> print q[0]
q1

Typically, I would get around this annoyance by unpacking the list:
q1, q2, q3, q4, q5 = q

However, if the generalized coordinates of PyDy were 0-indexed, you
could dispense with this step and just use q[0] to mean the
generalized coordinate q0.

This leads into the next issue, which is how you access the
UnitVectors of a ReferenceFrame. Currently this is done by
overloading the .__getitem__ method in the ReferenceFrame class, and
valid indices are the integers 1, 2, and 3. In the literature, the
two most common ways of denoting these basis unit vectors is either
with subscripts x, y, and z, or with subscripts 1, 2, and 3. I have
seen once or twice the indices be 0, 1, and 2, but I don't remember
where and this is definitely the exception not the rule. All of the
discussion of Euler angles and Space fixed rotations stick with this
convention, people talk of 312 Euler Angles, or equivalently, ZXY
Euler angles.

It seems to me that it would be confusing to use 0 based indexing of
generalized coordinates/speeds in conjuction with 1 based indexing for
the UnitVectors.

So here is what makes sense to me:

1) Use 0-based indexing for generalized coordinates and speeds in the
declare_coords and declare_speeds methods. For example:
>>> q, qd = N.declare_coords('q', 3)
>>> print q
[q0, q1, q2]

instead of:
>>> print q
[q1, q2, q3]

2) Change the way you access a reference frame's unit vectors from
the __getitem__ method (i.e. using [1]), to be instead three class
attributes, x, y, and z. For example, the new behavior would be:
A = ReferenceFrame('A')
new_vector = 2*A.x + 10*A.y + 13*A.z

instead of:
new_vector = 2*A[1] + 10*A[2] + 13*A[3]

I think that this approach is nice because it allows two non-
conflicting conventions to be followed, namely, consistent zero based
indices for symbols representing generalized coordinates and speeds,
so that lists of them can be manipulated and accessed in a more
natural way, and x-y-z conventions for UnitVectors, so there is no
conflict between 1-2-3 conventions (1 based indexing) for UnitVectors
and 0 based indexing for generalized coordinates. Additionally,
typing A.x is one character less than having to type A[1].

Thoughts?

~Luke

[Luke]

Discussion of why numbering should start at zero, by E.W. Dijkstra:
http://www.cs.utexas.edu/users/EWD/transcriptions/EWD08xx/EWD831.html

This is what Python does with lists/tuples.

~Luke

[Ondrej Certik]

In general I think all (python) lists should start from 0, as well as
numpy arrays and anything else.

x-y-z convention as you proposed above looks good. In the
special/general relativity, one uses

x_mu = (x_0, x_1, x_2, x_3)

where x_1, x_2 and x_3 are (x, y, z) tuple, and x_0 is time. So I
agree that in all books I know one always uses 1 for x, 2 for y and 3
for z. Never from 0.

So either I would introduce time into A[0], if it makes sense in pydy,
or just do

Ax, Ay, Az = A

So I think I agree with your conclusions.

Ondrej