You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Since Octionion has been split into Octonions.jl, both Quaternions.jl and Octonions.jl exports imag_part. This causes the following problem:
julia>using Quaternions, Octonions
julia> imag_part
WARNING: both Octonions and Quaternions export"imag_part"; uses of it inmodule Main must be qualified
ERROR: UndefVarError: imag_part not defined
Octonions.jl has a dependency on Quaternions.jl, so we can avoid this issue by adding the method Quaternions.imag_part(::Octonion). However, this approach is not good because the dependency on Quaternions.jl should be removed just like #62.
Therefore, I think the best approach here is renaming imag_part to imag_quat (and imag_octo).
The text was updated successfully, but these errors were encountered:
I think whether this is a problem depends on if we think users are likely to load Quaternions and Octonions at the same time. I don't have a good sense for whether this is likely. If it is, then I agree with this suggestion.
An alternative would be to define a base package HyperComplexNumbers that defines methods that would be relevant for any hypercomplex number, but I lean against this. For one thing, I don't want to design or maintain that package. For another, what would a function like imag_part do when we have numbers that combine multiple hypercomplex numbers like dual quaternions or biquaternions?
However, this approach is not good because the dependency on Quaternions.jl should be removed just like #62.
Since
Octionion
has been split into Octonions.jl, both Quaternions.jl and Octonions.jl exportsimag_part
. This causes the following problem:Octonions.jl has a dependency on Quaternions.jl, so we can avoid this issue by adding the method
Quaternions.imag_part(::Octonion)
. However, this approach is not good because the dependency on Quaternions.jl should be removed just like #62.Therefore, I think the best approach here is renaming
imag_part
toimag_quat
(andimag_octo
).The text was updated successfully, but these errors were encountered: