JuliaGeometry / Quaternions.jl

A Julia implementation of quaternions
https://juliageometry.github.io/Quaternions.jl
MIT License
116 stars 37 forks source link

Rename `imag_part` to `imag_quat`? #103

Open hyrodium opened 1 year ago

hyrodium commented 1 year ago

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 in module 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).

sethaxen commented 1 year ago

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 https://github.com/JuliaGeometry/Quaternions.jl/issues/62.

Agreed!