Question about ordering of basis bivectors

I come from a background of screw theory for rigid body mechanics and was pleasantly surprised when I discovered PGA as it addresses a lot of my gripes and inconsistencies.

Anyway, in my thesis I stated that twists (motors) and wrenches (forques) are lines in Plucker coordinates plus a pitch and magnitude.

Lines in 3D PGA are the following basis vectors

So for example,

  • To encode a force \vec{F}=(F_x,F_y,F_z) you would use {\bf f} =F_z{\bf e}_{12}+F_y{\bf e}_{31}+F_x{\bf e}_{23}
  • To encode a torque \vec{\tau}=(\tau_x,\tau_y,\tau_z) you would use {\bf f} =\tau_x{\bf e}_{01}+\tau_y{\bf e}_{02}+\tau_z{\bf e}_{03}

The way these are ordered in code would be

f = [0, 0,0,0, τx,τy,τz,Fz,Fy,Fx, 0,0,0,0, 0]

I wish the ordering would be different such as the familiar cadence of (x,y,z) is maintained, and each basis vector would be the same sequence as its dual vector.

\star\begin{pmatrix}{\bf e}_{01} & {\bf e}_{02} & {\bf e}_{03}\end{pmatrix}=\begin{pmatrix}{\bf e}_{23} & {\bf e}_{31} & {\bf e}_{12}\end{pmatrix}

\star\begin{pmatrix}{\bf e}_{1} & {\bf e}_{2} & {\bf e}_{3}\end{pmatrix}=\begin{pmatrix}{\bf e}_{032} & {\bf e}_{013} & {\bf e}_{021}\end{pmatrix}

and vice-versa.

a similar problem exists for encoding the point (x,y,z)

P=[0, 0,0,0, 0,0,0,0,0,0, z,y,x,1, 0]

This can be achieved with the following ordering:


\begin{array}{ccccc} \underbrace{1}_{\text{scalar}} & \underbrace{\left(\begin{array}{c|ccc} {\bf e}_{0} & {\bf e}_{1} & {\bf e}_{2} & {\bf e}_{3}\end{array}\right)}_{\text{vector(plane)}} & \underbrace{\left\{ \begin{array}{ccc|ccc} {\bf e}_{01} & {\bf e}_{02} & {\bf e}_{03} & {\bf e}_{12} & {\bf e}_{31} & {\bf e}_{23}\end{array}\right\} }_{\text{bivector(line)}} & \underbrace{\left[\begin{array}{ccc|c} {\bf e}_{021} & {\bf e}_{013} & {\bf e}_{032} & {\bf e}_{123}\end{array}\right]}_{\text{trivector(point)}} & \underbrace{{\bf e}_{0123}}_{\text{pseudo-scalar}}\end{array}


\begin{array}{ccccc} \underbrace{1}_{\text{scalar}} & \underbrace{\left(\begin{array}{c|ccc} {\bf e}_{0} & {\bf e}_{1} & {\bf e}_{2} & {\bf e}_{3}\end{array}\right)}_{\text{vector(plane)}} & \underbrace{\left\{ \begin{array}{ccc|ccc} {\bf e}_{01} & {\bf e}_{02} & {\bf e}_{03} & {\bf e}_{23} & {\bf e}_{31} & {\bf e}_{12}\end{array}\right\} }_{\text{bivector(line)}} & \underbrace{\left[\begin{array}{ccc|c} {\bf e}_{032} & {\bf e}_{013} & {\bf e}_{021} & {\bf e}_{123}\end{array}\right]}_{\text{trivector(point)}} & \underbrace{{\bf e}_{0123}}_{\text{pseudo-scalar}}\end{array}

Now the dual() operator should be easier as no re-ordering of coefficients is needed (going from point to plane for example). As you can see below the Hodge dual operator should maintain the same cadence.

Or am I wrong in the interpretation of how to encode the familiar line and axial vectors as bivectors?

PS. The Cayley Table should now contain the familiar wedge/cross-product operator matrix \begin{bmatrix}0 & -v_{z} & v_{y}\\ v_{z} & 0 & -v_{x}\\ -v_{y} & v_{x} & 0 \end{bmatrix}

Hi JA72,

Welcome to PGA!

The ordering we have taken is symmetric in the sense that dualization of a multivector mirrors it around the center of the table. In a sense, that is more ‘natural’, because geometrical, than anything based on a fixed reading order. But many people tend to call their own convention ‘natural’, so we better not go there.

At least our ordering is partly physical since it treats the axes symmetrically. In computer science, a common order is alphabetic/lexicographic which has 12, 13, 23 and gives different signs within grades. It is a common source of mistakes.

Of course PGA is also applicable to higher-D spaces, and then the 3D cyclicity has to be abandoned anyway; so then one may revert to the CS order.
In the end, you do not use coordinates in your specification, that is what GA in general allows, so this is a detail of the implementation. Once the basic vector order has been decided, the labelling and combination of the higher-grade objects and where to store them can be done by automatic software, or even in the compiler.

But you are right to be cautious: always check whatever convention is used when combining multiple sources…

Leo Dorst

1 Like