I think I can agree with all of that. Thanks for helping me work this out!
Ian Tickle wrote:
We come up with the same conclusions with our different ways of thinking
about it:
for one, deriving the concatenated simple operators to represent a general
rotation,
and the commutativity: I would say the operators do not commute as long as
the axes
they rotate about are kept fixed, but if the axes rotate the same as the
molecule
then the z axis will always be passing through the atoms the same way.
Then rotations would commute, because the z axis would always represent the
same
molecular axis. Which I am sure is NOT what you meant by saying "new z
axis".
Simple rule: in the general case rotation matrices _never_ commute (only in the
special
cases I described earlier). The fallacy in your argument is that you are
referring to
molecular basis axes: in the screen basis convention that we are using the
rotation axis
directions must always be with respect to the screen basis axes, even if we are
talking
about the rotated axis interpretation of the above equation; in that case they
are
therefore by definition in general different axes, both in name ('z' & 'new z')
and in
direction, and therefore cannot possibly commute.
I think we are saying the same thing here. When I say the axes are kept fixed, I mean they
are the screen axes. When you say "new axis" you do not mean that the axis has been
rotated, but that it passes through the molecule differently. Or maybe not . . .
Looking at the math, it depends whether you multiply from right to left or left
to right
x' = Rz(a) Ry(b) Rz(g) x
or
x' = Rz(a) (Ry(b) (Rz(g) x))
Mathematically this is easiest going from right to left: apply the gamma rotation to the
coordinates, then the beta rotation to that result, then the alpha rotation to that
result. This way all three rotations are simple rotations about the principle screen axes.
If we insist on thinking about it left to right, then the leftmost operator operates on
the other two (and the middle operates on the right-most) and so by the time they get
applied they are "new".
But I'm not sure it is even possible to do the math that way. As far as I see it, the only
mathematical interpretation of this equation is first rotate the coordinates by gamma
about z, then rotate the result by beta about y, then rotate the result by alpha about z.
Sure, you can multiply the three matrices together and operate on the coordinates with
that, but i don't see how that corresponds to "first rotate by alpha around z then . . .)"
And since the operators don't commute, you can't factor it in like:
Rz(a) (Ry(b) (Rz(g) x))
!= Rz(a).Ry(b).Rz(g) x) . (Rz(a).Ry(b) x) . (Rz(a) x)
gamma@newZ . x beta@newY . x alpha@oldZ.x
(or any such nonsense)
so I wonder if you could even come up with mathematical definitions of new Y
and new Z.
However this looks very simple with the aforementioned Eulerian navigator toy: if you
start rotating the outside ring and work inwards, each time you are rotating about a
previously rotated axis, and one could surely calculate what those new axes are in terms
of the rotations already applied. But it sure is simpler going the other way!
Ian Tickle wrote:
For reasons I find hard to fathom virtually all program documentation seems to
describe it
in terms of rotations about already-rotated angles. If as you say you find
this confusing
then you are not alone! However it's very easy to change from a description
involving
'new' axes to one involving 'old' axes: you just reverse the order of the
angles. So in
the Eulerian case a rotation of alpha around Z, then beta around new Y, then
gamma around
new Z (i.e. 'Crowther' convention) is completely equivalent to a rotation of
gamma around
Z, then beta around _old_ Y, then alpha around _old_ Z.
I'm happy to leave it at that. Except now I'm unsure about the definition of
alpha and gamma.
eab
