Closed hyrodium closed 9 months ago
All modified and coverable lines are covered by tests :white_check_mark:
Comparison is base (
2055de5
) 100.00% compared to head (670aa2a
) 100.00%.
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
In my opinion, any code that mixes complex numbers and quaternions is doing the wrong thing. We're already explicit that there's no natural embedding of complex numbers in the quaternions, and I think it's perfectly fine if we don't have an equality method between quaternions and complex numbers at all, so that even pure real complex numbers and quaternions are unequal.
If every hypercomplex number type needed to add an equality method like this for every other hypercomplex number type, we would have combinatorial explosion and probably lots of unintended ambiguities.
Thank you for the comment! I agree with that and close this PR.
Overview
Before this PR
After this PR
Why add methods?
Base has the following
==(::Real, ::Complex)
and==(::Complex, ::Real)
definitions.https://github.com/JuliaLang/julia/blob/e7345b89fd4eb15e8f395395701e19be705d7b06/base/complex.jl#L247-L249
Quaternions.jl should have methods similar to these, instead of
==
by type promotions.How about compatibility with the
Complex
type?There were the following choices for the design:
==(::Complex, ::Quaternion)
always throws an error.==
do not throw an error (e.g."foo" == :foo
), so it would be consistent with Base if we avoid throwing errors for that.==(z::Complex, q::Quaternion)
returnstrue
ifc.re==q.s && c.im==q.v1 && q.v2==q.v3==0
, otherwise returnsfalse
.Complex
(https://github.com/JuliaGeometry/Quaternions.jl/pull/113).==(::Complex, ::Quaternion)
returnstrue
only if these are real and equal, otherwise throws an error.==(::Complex, ::Quaternion)
returnstrue
only if these are real and equal, otherwise returnsfalse
.