Continuing the discussion from Taking Quaternions Seriously:
This is simply not true.
This is almost exactly what Quaternions.jl (old, practically unmaintained) did:
To represent rotations, we’re really only interested unit quaternions, so in Rotations.jl the UnitQuaternion
type basically asserts isnorm
at compile time and tries to avoid renormalizing whenever that makes sense, avoiding performance costs but placing some burden on the user to ensure that numerical inaccuracies after several operations are kept in check. A type parameter that captures whether or not the quaternion is normalized (as mentioned) is also fine, but in Rotations.jl there has not really been a need for unnormalized quaternions.
This would have very severe performance consequences that are unacceptable in a lot of applications.
I think the fact that different users have different requirements in terms of performance, accuracy, memory layout, mathematical underpinnings, focus on rotation / interop with other rotation representations vs. support for unnormalized quaternions, as well as package dependencies means that it’s OK for there to be more than one implementation in the Julia package ecosystem. Of course, do consider contributing to an existing package before writing another implementation.