# Taking Quaternions Seriously

**URL:** <https://discourse.julialang.org/t/taking-quaternions-seriously/44834>\
**Category:** Numerics\
**Created:** [August 12, 2020, 10:45pm UTC](https://discourse.julialang.org/t/taking-quaternions-seriously/44834 "2020-08-12T22:45:16Z")\
**Posts on this page:** 1\
**Showing post:** 44

<div class="post-metadata">

**Author:** ![Ronis\_BR](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/ronis_br/32/50999_2.png) [@Ronis\_BR](https://discourse.julialang.org/u/Ronis_BR)\
**Post date:** [August 19, 2020, 12:50pm UTC](https://discourse.julialang.org/t/taking-quaternions-seriously/44834/44 "2020-08-19T12:50:03Z")

</div>

> [@tuckermcclure](#):
>
> - I seem to recall seeing Rotations.jl implement rotation operations by going to matrices and then back to the desired parameterization for the output. (Please let me know if I’m mistaking this with another package.) This loses more accuracy than dedicated operations for each parameterization. The difference would actually be the biggest source of error for, say, geographic surveying. The important part here doesn’t have anything to do with Rotations.jl, but is simply that there are many, many methods for working with this stuff, according to different needs.
> - Both aircraft and spacecraft folks tend to work with frame rotations, whereas (in my limited experience) robotics folks seem to like vector rotations (opposite conventions).

I completely agree. Those are the two reasons why I kept maintaining [ReferenceFrameRotations.jl](https://github.com/JuliaSpace/ReferenceFrameRotations.jl) after Rotations.jl.

---

_[View the full topic](https://discourse.julialang.org/t/taking-quaternions-seriously/44834)._