Closed hyrodium closed 1 year ago
Hi @hyrodium !
In a typical scenario, I would say why not! However, ReferenceFrameRotations.jl is used here at INPE for satellite simulators and analyses.
Since we do not have time right now to update all the tools we have, the migration must respect some points:
stdout
.If you are willing to adapt Quaternions.jl to attend those points, we can try to integrate it with ReferenceFrameRotations.jl :) However, I fully understand if you decide not to since those are not common asks in open-source development.
I am really sorry for those demands, but this package is really crucial for daily work here.
Thank you for the detailed comment!
Everything must be the same, with no API or breaking changes. This includes, for example, the naming convention for the quaternion elements and the output print to stdout.
This is probably the hardest one: the operations must use the same equations in the same order. All the code is tested by comparing the result to machine epsilon to ensure nothing changes. Hence, I am pretty sure that if we use different ordering when computing, for example, the quaternion multiplication, it will lead to different results when analyzing the least significant bits.
I think we will not change Quaternions.jl just for adapting ReferenceFrameRotations.jl, so let's keep avoiding the migration of Quaternion
.
However, in some cases, Quaternions.jl have better performance on overflow/underflow. Maybe there are more cases that one package has better performance than the other, so comparing these implementations and tests will be helpful to both packages.
julia> import Quaternions
julia> import ReferenceFrameRotations
julia> q1 = Quaternions.Quaternion(1e-300,0,0,0)
Quaternions.QuaternionF64(1.0e-300, 0.0, 0.0, 0.0)
julia> q2 = ReferenceFrameRotations.Quaternion(1e-300,0,0,0)
Quaternion{Float64}:
+ 1.0e-300 + 0.0⋅i + 0.0⋅j + 0.0⋅k
julia> abs(q1)
1.0e-300
julia> norm(q2)
0.0
However, in some cases, Quaternions.jl have better performance on overflow/underflow. Maybe there are more cases that one package has better performance than the other, so comparing these implementations and tests will be helpful to both packages.
Very good! Thanks for letting me know. I will really consider Quaternion.jl when we finish the current satellite project and have a window for big migrations :)
I will really consider Quaternion.jl when we finish the current satellite project and have a window for big migrations :)
Great!! Please reopen this issue if you need my help :hugs:
Sure! Thank you very much!
Hi! I'm a maintainer of Quaternions.jl, and I wonder if we can replace
ReferenceFrameRotations.Quaternion
withQuaternions.Quaternion
. Before 2022, Quaternions.jl was not well-maintained, but the package is now ready to be used in other packages. See my post on Julia discourse for more information.If this change is acceptable, I will be glad to open a PR. I think the hardest part of the migration is avoiding type piracy. (e.g.
Quaternion(u::UniformScaling{T})
should not be defined.)