improve promotion and equality checking

[mikmoore]

This PR is primarily motivated by an issue where Quaternion(1) == 1 returned false. There were two issues at play here.

First, convert(Quaternion,::Real) and convert(Quaternion,::Complex) were never setting the .norm field of the resulting Quaternion. This meant that Quaternion(1.0).norm == true while convert(Quaternion,1.0).norm == false.

Second, there was no special-cased ==(::Quaternion,::Quaternion) method. This meant that equality required the .norm fields to match.

This PR reroutes convert calls through the normal constructors to help .norm be set more consistently. It also adds a == method for Quaternions so that the .norm field is ignored in equality checks. Lastly, it adds some tests along these lines.

[dkarrasch]

Just a few minor style comments.

[dkarrasch]

This should close #40, IIUC.

[mikmoore]

I noticed that & is probably better than && for short chains of simple comparisons (no branches), so I changed that slightly although it can certainly be reverted.
I also extended this PR to include the matching changes to Octonion and DualQuaternion, which I had neglected before.

[codecov]

Codecov Report

Merging #52 (c333db7) into master (be0fc14) will increase coverage by 9.84%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master      #52      +/-   ##
==========================================
+ Coverage   45.58%   55.43%   +9.84%     
==========================================
  Files           3        3              
  Lines         351      359       +8     
==========================================
+ Hits          160      199      +39     
+ Misses        191      160      -31     

Impacted Files	Coverage Δ
src/DualQuaternion.jl	21.78% <100.00%> (+17.65%)	⬆️
src/Octonion.jl	28.04% <100.00%> (+18.04%)	⬆️
src/Quaternion.jl	87.50% <100.00%> (+2.44%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update be0fc14...c333db7. Read the comment docs.

[sethaxen]

Thanks for the PR! Can you add tests for == for Octonion and DualQuaternion as well? Also, most of the conversions modified here are not yet covered by tests, and they should be tested as well.

[sethaxen]

Sorry, accidentally approved before the missing tests were added.

[mikmoore]

I noted that the internal(?) shorthand functions quat, dualquat, and octo had the same issue of defaulting the norm field to false, in addition to being totally redundant. I redefined them to be constants equal to their corresponding type, which should fix that. In the grander scheme I think they really had ought to be removed, but that's beyond the scope of this PR.

I added explicit conversion tests. They revealed that DualQuaternion was broken when given DualNumbers.Dual because the field names were wrong. I believe I fixed that as well, but somebody should check because dual numbers aren't really my thing.

[sethaxen]

Aliasing the shorthand functions would be a breaking change. While the public API of this package is not documented, they are exported functions and should be considered part of the API. As for their use quat is to Quaternion as complex is to Complex. The former is a method the user can overload to quaternion-ify anything, while the latter is a constructor that should return a Quaternion (and probably should not be overloaded). You could open an issue to discuss removing them, but that really should not be in this PR.

[sethaxen]

This does not seem to be consistent with how norm is defined for DualQuaternion. norm returns a Dual number, and the DualQuaternion is normalized when the real part of the norm is 1 and the infinitesimal part is 0.

[sethaxen]

I think we only want to set norm=true when its value can be determined from either the types being provided or from the value of other norm fields, which I don't think we can do here.

[mikmoore]

I have zero knowledge of dual quaternions, hence my mistake. It appears this has veered wildly beyond the scope of both this PR and my understanding and I'll revert my change.

Off-topic discussion: wouldn't your statement imply that n::Bool = q0.norm & iszero(qe) would be the proper initialization? More importantly, doesn't any requirement on the infinitesimal part imply that normalize(::DualQuaternion) and friends are incorrect in setting norm=true without examining the infinitesimal? According to https://en.wikipedia.org/wiki/Dual_quaternion#Norm, however, it appears to be slightly less restrictive than what you have claimed. It says that a dual quaternion A+eB is unit when (AA*,AB*+BA*)=(1,0).

[sethaxen]

TBH, I don't have much experience with dual quaternions either, so I can't really answer the questions without digging into the code and the theory a bit more. My point was just that the change would create inconsistencies in the code base.

[sethaxen]

Also, can you rebase on master and resolve merge conflicts?

[mikmoore]

As for their use quat is to Quaternion as complex is to Complex.

I see. In that case, I changed them to not default norm=false but instead to only forward a norm flag if provided one. This will let them inherit default norm behavior from the relevant constructors. Without this change, for example, Quaternion(1) and quat(1) resulted in different norm flags.

[sethaxen]

If you browse through the code, CodeCov has annotated a few lines changed here that are not covered by the tests. Can you check that they are? Also, can you add tests that the shorthand cases you mentioned where norm was set differently than by the constructor are also tested?

[sethaxen]

LGTM, thanks!