First, from this software implementation perspective, we are bypassing the discussion of interpretation altogether.
For example, in Python, we could make a Rotation object callable:īut wait– we’ve already made several choices of convention here, at least implicitly.
We can view the concept of rotation as a group acting on, with a particular rotation represented as a group element, that transforms a vector into a new rotated vector. Let’s start with the interface first, then we will flesh out the implementation. To try to show more clearly how silly this situation is, let’s think like a software developer, working out how to implement rotations for some application. But even if this is old news for you, then I will try to argue that use of this evil twin quaternion, advocated by Shuster as the “natural” convention, was an unnecessary choice… and certainly not any more “natural,” “physical,” or otherwise inherently preferable to the quaternion most of us are familiar with. If you didn’t already know this, then hopefully this post is a helpful warning to double-check your documentation and code. The unit quaternion, familiar to most of us as a way to represent rotations in many application domains, has an evil twin. This post is motivated by lost and delayed productivity, stemming from confusion and miscommunication about one of these choices that seems not widely known: there are two different quaternions out there in the wild. Are we “actively” rotating vectors, or “passively” rotating frames? If the latter, are we rotating from the “body” to “world” frame, or from world to body? Are rotations applied as we write them left to right, or right to left? Are the rotations right-handed or left-handed? Etc. I think the reason that 3D rotations can be tricky to work with is that there are so many choices of convention– in interpretation, notation, and implementation– and we often do not communicate or document all of those choices clearly and completely.
0 kommentar(er)
