I can't comment on the DSP applications in the article, but for representing rotations and orientations in 3D (Computer rendersing, robotics, aerospace etc), th

I can't comment on the DSP applications in the article, but for representing rotations and orientations in 3D (Computer rendersing, robotics, aerospace etc), they can be effectively treated as black boxes. There are a handful of operations you can perform between quaternions and other quaternions, vectors, and scalers, to do anything you would want in this domain. Practially, you may just be calling functions like "Quaternion::from_unit_vecs()` etc. Call it a Rotor if you'd like; it doesn't matter when viewing it this way! Both implementation and application will be the same. The conceptual aspect people prefer about rotors is N/A here. You could also call it a `Orientation` or `Rotation` (eg the struct/class name); maybe that's better than either.