ENH: Force real part of Rotation.as_quat() to be positive.

[alexander-soare]

Is your feature request related to a problem? Please describe.

No response

Describe the solution you'd like.

I think that any return value of Rotation.as_quat() should have a non-negative real component. This means we don't have to worry about the fact that quaternions are a double cover on SO(3) and we can always predict what the quaternion components will be given a rotation.

Describe alternatives you've considered.

Consider a Rotation instance: r = Rotation.random(). And consider the quaternion components I get from it: q = r.as_quat(). I can force the real part to be positive without changing the physical significance of the quaternion

if q[-1] < 0:
    q = -q

Additional context (e.g. screenshots, GIFs)

No response

[scottshambaugh]

Note that with the proposed solution above there are still dual points when the scalar component of q is exactly 0, and this extends to the other components. There's probably a more efficient way to write this, but to get a complete 2-to-1 mapping to a unique "positive" quaternion for every rotation, this is the required logic:

if ((q[3] < 0)
    or (q[3] == 0 and q[0] < 0)
    or (q[3] == 0 and q[0] == 0 and q[1] < 0)
    or (q[3] == 0 and q[0] == 0 and q[1] == 0 and q[2] < 0)):
    q = -q

[alexander-soare]

Perhaps more efficient because it avoids rechecking the same thing twice?

for c in np.roll(q):
  if q > 0:
    break
  elif q < 0:
    q = -q
    break

[alexander-soare]

@scottshambaugh thanks for picking this up. The c stuff was intimidating me but now that I've watched you do it I'll have a crack at it myself next time.

Btw would it still be more efficient to use a for loop on this one rather than rechecking those conditions? Perhaps for index in [3, 0, 1, 2] instead of the np.roll?

[scottshambaugh]

@alexander-soare it should all be optimized by the compiler to the same thing, but that might be easier to read so I updated it.

[alexander-soare]

@scottshambaugh cool, yeah still getting used to the magic of C compilers.

[scottshambaugh]

Psyche, there's an issue defining local arrays in cdef's and working around it would be even messier, so I reverted to the old logic.

[matusvalo]

Psyche, there's cython/cython#3160 defining local arrays in cdef's

FYI. the issue was just now fixed and should be released with the next cython 3.0 release.