Grassmann.jl vs Quaternions.jl

[chakravala]

Grassmann.jl has its own dedicated Quaternion type for a while now, I've been focused on smoothing out various general things related to this package. Now things have stabilized and smoothed out again, I can look into further standardizing the quaternion interface. Grassmann.jl supports quaternions in a much more general way, but it the definitions are such that k = -v13

julia> using Grassmann; basis"3"
(⟨×××⟩, v, v₁, v₂, v₃, v₁₂, v₁₃, v₂₃, v₁₂₃)

julia> s,i,j,k = v,v12,-v13,v23
(v, v₁₂, -1v₁₃, v₂₃)

julia> i*j == k
true

julia> quatvalues(s+2i+3j+4k)
4-element StaticVectors.Values{4, Int64} with indices SOneTo(4):
 1
 2
 3
 4

julia> v1 ⊘ exp(π*i/2)
-1.0v₁ + 1.2246467991473532e-16v₂ + 0.0v₃

julia> v1 ⊘ exp(π*i/4)
2.220446049250313e-16v₁ + 1.0v₂ + 0.0v₃

julia> v1 ⊘ exp(π*i/8)
0.7071067811865475v₁ + 0.7071067811865476v₂ + 0.0v₃

julia> (v1+v2+v3) ⊘ exp(π*i/8+j*π/3)
-0.1577202379738252v₁ + 1.6085211528719414v₂ - 0.6227230743251773v₃

If anybody has anything to say about this, let me know.

[hyrodium]

Hi, thank you for maintaining Grassmann.jl!
I think https://juliapackagecomparisons.github.io/comparisons/math/quaternions/ (and its repo) is the right place to discuss the comparisons between these packages.

If you would like to add compatibility with Quaternions.jl to Grassmann.jl, it would be reasonable to define some methods in a package extension. Feel free to contact me if you have any problems! I'm happy to help with that.

[chakravala]

If you would like to add compatibility with Quaternions.jl to Grassmann.jl, it would be reasonable to define some methods in a package extension.

I'm certainly open to this approach; however, I'm not sure I personally need it, so I will leave it to somebody else to make the pull requests for that, which I'm willing to help out with but don't necessarily have my own necessity for. Unless somebody explains to me what the steps are and how much work this is.

My work is mostly based purely on building on Grassmann.jl and Makie.jl and I mostly don't bother with other systems not based on Grassmann.jl so people from the outside may need to provoke all that.

You are the people on the outside who worry about things not currently based on Grassmann.jl so you are those people who need to take responsibility over those things, I'm available to respond to the needs of a Quaternions.jl interface but don't necessarily need to motivate it in my own personal work.

Right now is the time to engage this topic, as of yesterday Grassmann.jl has matured to a new milestone with regards to quaternion usage, so any opinions or conclusions before yesterday no longer apply.

[chakravala]

Grassmann.jl does not implement Quaternion as a struct, but quaternions are realized as an alias Grassmann.Quaternion (alias for Spinor{V, T, 4} where {V, T}).

While a quaternion is an even grade element, in Grassmann the exterior algebra basis of 3 independent dimensions is used to represent tensors in a combinatorial way. There are several ways to assign i,j,k with Grassmann elements, perhaps the standard would be i = v12, j = -v13, k = v23 (although this is not a unique choice). Since j and v13 have opposite sign in this notation, the quatvalues method is exported to output the coefficients with the convention s,i,j,k with the sign convention mentioned for convenience. The basis elements v12,v13,v23 are sparse and do not assign a full 4 value quaternion unless combined with algebra, which is not confined to only quaternion algebra in this package.

julia> using Grassmann; basis"3"
(⟨×××⟩, v, v₁, v₂, v₃, v₁₂, v₁₃, v₂₃, v₁₂₃)

julia> s,i,j,k = v,v12,-v13,v23
(v, v₁₂, -1v₁₃, v₂₃)

julia> i*j == k
true

julia> quatvalues(s+2i+3j+4k)
4-element StaticVectors.Values{4, Int64} with indices SOneTo(4):
 1
 2
 3
 4

As a result of the framework of geometric algebra implemented in Grassmann, vector algebra and quaternion algebra are compatible in a unified formalism. Given a quaternion operator R and a vector x the operator can be applied with either the R>>>x (evaluated as R*x*conj(R) operator) or x⊘R (evaluated as conj(R)*x*R operator) to transform vectors with quaternions.

julia> v1 ⊘ exp(π*i/2)
-1.0v₁ + 1.2246467991473532e-16v₂ + 0.0v₃

julia> v1 ⊘ exp(π*i/4)
2.220446049250313e-16v₁ + 1.0v₂ + 0.0v₃

julia> v1 ⊘ exp(π*i/8)
0.7071067811865475v₁ + 0.7071067811865476v₂ + 0.0v₃

julia> (v1+v2+v3) ⊘ exp(π*i/8+j*π/3)
-0.1577202379738252v₁ + 1.6085211528719414v₂ - 0.6227230743251773v₃

A rotation matrix could be obtained from the input of v1,v2,v3 into the operator.

[sethaxen]

I don't see any particular need for integration between Quaternions and Grassmann:

• the packages seem to have very different scopes
• there are multiple packages that implement quaternions without integrating with each other; this is fine
• it sounds like neither you nor we are needing or asking for an integration, nor have any users of our packages. Integration without a use case for it would be premature.

[chakravala]

I don't see any particular need for integration between Quaternions and Grassmann:

If you don't see a need for being in this discussion, then your comments are probably not needed either.

it sounds like neither you nor we are needing or asking for an integration

You are mistaken, Grassmann.jl is fully integrated into my work and I would not want quaternions outside of Grassmann.jl ... it is inevitable that things will be built on Grassmann.jl and from my perspective all the work depending on quaternions without Grassmann.jl are basically deprecated.

I am an officially banned Julia community outcast, so I never bother to ask the Julia community for anything. It's up to you to provoke these things to move forward, as a banned outcast I'm not part of the discussion.

I am not asking for anything, I am letting you know that Grassmann.jl v0.8.14 makes other quaternion packages completely obsolete and deprecated in terms of having full sophistication with computational mathematics.

You can keep building on deprecated software, but the foundation has been laid for deeper and more sophisticated ways of interacting with quaternions.

[ronisbr]

You can keep building on deprecated software, but the foundation has been laid for deeper and more sophisticated ways of interacting with quaternions.

I just want to add an information here for future readers of this thread.

There is a huge number of applications using quaternions and each one has its own specificities. For example, I work with the attitude control subsystem of satellites. For us, quaternions are a good attitude representation. However, we see them as a 4 x 1 vector with real numbers and we only need to implement quaternion multiplication and its conversion to direct cosine matrices, Rodriguez parameters, Euler angles, etc. With only those algorithms, we can control the satellite attitude (it is almost the same with airplanes).

Now, I am seeking to develop an entire AOCS system using Julia language in a CubeSat. We have huge constraints on memory and processing power. Let's see how much time it takes to import each package:

julia> @time using Grassmann
  0.218593 seconds (354.27 k allocations: 27.317 MiB, 1.45% compilation time)

julia> @time using ReferenceFrameRotations
  0.144537 seconds (278.27 k allocations: 15.431 MiB, 1.52% compilation time)

julia> @time using Quaternions
  0.004729 seconds (9.21 k allocations: 728.609 KiB)

Hence, for my application, I will probably use Quaternions.jl and "copy" the required algorithm from ReferenceFrameRotations.jl to convert them to DCMs. Those timings show that Quaternions.jl probably has a significant smaller footprint compared to the other ones.

My point here is that having a way more complex package as Grassmann.jl that can provide an excellent workspace to deal with quaternion algebra does not turn every other package that defines quaternion deprecated.

[chakravala]

Thanks for loading time comparison, I have never made the comparison myself. While Grassmann.jl seems to take a long time to load, it simultaneously is also a replacement for StaticArrays, and Grassmann.jl has the same load time as StaticArrays.jl Therefore, Grassmann.jl actually is still a better choice than Quaternions or StaticArrays, as it is able to replace both packages at once with a single dependency. It still stands that Grassmann.jl is a better option, especially if you need to load a StaticArray package anyway for 4×4 matrices. So overall, seems Grassmann.jl is the winner here, it will be able to replace both StaticArrays and Quaternions simultaneously, and also provides much more mathematical features than those two packages combined. While the load time of Grassmann.jl may seem long compared to pure quaternions, it is very likely that you need to work with StaticArrays anyway, thus negating the gain. Grassmann.jl is able to kill multiple birds with one stone.

…

On Sun, May 12, 2024, 7:05 PM Ronan Arraes Jardim Chagas < ***@***.***> wrote: You can keep building on deprecated software, but the foundation has been laid for deeper and more sophisticated ways of interacting with quaternions. I just want to add an information here for future readers of this thread. There is *a huge* number of applications using quaternions and each one has its own specificities. For example, I work with the attitude control subsystem of satellites. For us, quaternions are a good attitude representation. However, we see them as a 4 x 1 vector with real numbers and we only need to implement quaternion multiplication and its conversion to direct cosine matrices, Rodriguez parameters, Euler angles, etc. With only those algorithms, we can control the satellite attitude (it is almost the same with airplanes). Now, I am seeking to develop an entire AOCS system using Julia language in a CubeSat. We have huge constraints on memory and processing power. Let's see how much time it takes to import each package: julia> @time using Grassmann 0.218593 seconds (354.27 k allocations: 27.317 MiB, 1.45% compilation time) julia> @time using ReferenceFrameRotations 0.144537 seconds (278.27 k allocations: 15.431 MiB, 1.52% compilation time) julia> @time using Quaternions 0.004729 seconds (9.21 k allocations: 728.609 KiB) Hence, for my application, I will probably use Quaternions.jl and "copy" the required algorithm from ReferenceFrameRotations.jl to convert them to DCMs. Those timings show that Quaternions.jl probably has a significant smaller footprint compared to the other ones. My point here is that having a way more complex package as Grassmann.jl that can provide an excellent workspace to deal with quaternion algebra does not turn every other package that defines quaternion deprecated. — Reply to this email directly, view it on GitHub <#146 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEMFOEHHLADYDP3JEHGNQMTZB7YTVAVCNFSM6AAAAABGMJYSI2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMBWGQYDGMBSGQ> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[ronisbr]

This information is very nice indeed! Thanks for sharing!

[chakravala]

Also, it is theoretically possible to separate the sub-algebra used for quaternions from the main Grassmann.jl package, if faster load times are truly desired. However, I have not been convinced as of now that the trade-off with maintainance of split packages is worth it at this time. Perhaps when v1.0 is released (which is coming this year) it can be potentially split off so that quaternions can be loaded quicker. It may not be a good idea though, so I will wait until the v1.0 release cycle of Grassmann.jl to decide such things.

…

On Sun, May 12, 2024, 7:57 PM Ronan Arraes Jardim Chagas < ***@***.***> wrote: This information is very nice indeed! Thanks for sharing! — Reply to this email directly, view it on GitHub <#146 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEMFOEGCEPT34CZOSLESN33ZB76WHAVCNFSM6AAAAABGMJYSI2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMBWGQYTMOBVGA> . You are receiving this because you authored the thread.Message ID: ***@***.***>