1. Glotzer Group Avatar Glotzer Group
  2. Analysis tools
  3. rowan
  4. Issues

Don't require unit quaternions in some functions

Issue #6 closed
Matthew Spellings created an issue

Non-unit quaternions are useful for specifying a simultaneous scaling and rotation. rowan.rotate, at least, currently checks whether the quaternions are unit quaternions twice(!), but I think that applying a rotation + scaling via non-unit quaternions is reasonable. Do we have any use cases in mind where the unit quaternion assertions are particularly helpful?

Comments (6)

  1. Vyas Ramasubramani

    The unit quaternion checks are mostly there as sanity checks because the vast majority of use-cases don't involve scaling, but it's relatively easy to forget to normalize a quaternion. I'd be open to allowing the scaling, but I would be hesitant to completely remove sanity checks. Do you think they're completely unnecessary?

    The double check is definitely an unnecessary holdover from before the _validate_unit function was defined and can be removed.

  2. Matthew Spellings reporter

    I would say it should depend on the function in question, but as long as the function's behavior doesn't require it, any quaternion---unit or not---should be accepted. If I recall correctly the conversion to a rotation matrix does require a unit quaternion (in the form listed on wikipedia), for example, but I think that it would be useful to remove the restriction from rotate, at least.

  3. Vyas Ramasubramani

    The algorithms for quaternion<->rotation matrix interconversion in rowan support non-unitary matrices and non-unit quaternions, but in both cases the functions (to_matrix and from_matrix) error by default if such arguments are provided; an additional boolean flag argument indicates that the user knows what they're doing when such an argument is provided. Particularly in those conversion cases, as a user I would prefer to be warned when I forgot to normalize my quaternion (e.g. due to build-up of round-off error after many multiplications), even at the expense of having to provide an extra argument when I want to use non-unitary matrices.

    But in general I see your point that if the math works for quaternions we should support it. Do you think that we should just move the onus onto the user to ensure that quaternions are appropriately normalized? Or perhaps introduce a new boolean flag to methods like rotate where users tell rowan to error out if things are not appropriately normalized? The latter is unappealing to me from an API perspective, but appealing from a usability perspective.

  4. Matthew Spellings reporter

    Since FP math makes any tests inexact anyway, I would think it's best to just use the quaternion that the library is given for functions that don't require it. I don't think any changes would need to be made to the API; I think if the user doesn't know what they are doing and are dealing with pure rotations, they would get unit quaternions from rowan or hoomd anyway, rather than concocting their own.

  7. Log in to comment
Assignee
–
Type
proposal
Priority
minor
Status
closed
Votes
0
Watchers
1
Jira: the preferred issue tracker for Bitbucket. Join the team!