-
Notifications
You must be signed in to change notification settings - Fork 37
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
improve promotion and equality checking #52
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just a few minor style comments.
This should close #40, IIUC. |
better styling and formatting Co-authored-by: Daniel Karrasch <[email protected]>
I noticed that |
Codecov Report
@@ 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
Continue to review full report at Codecov.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Co-authored-by: Seth Axen <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry, accidentally approved before the missing tests were added.
Co-authored-by: Seth Axen <[email protected]>
…orm field. but they should probably be removed altogether.
I noted that the internal(?) shorthand functions I added explicit conversion tests. They revealed that |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
src/DualQuaternion.jl
Outdated
@@ -6,29 +6,29 @@ struct DualQuaternion{T<:Real} <: Number | |||
norm::Bool | |||
end | |||
|
|||
DualQuaternion(q0::Quaternion, qe::Quaternion, n::Bool = false) = | |||
DualQuaternion(q0::Quaternion, qe::Quaternion, n::Bool = q0.norm) = |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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)
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Also, can you rebase on master and resolve merge conflicts? |
Co-authored-by: Seth Axen <[email protected]>
…wrong .norm field. but they should probably be removed altogether." This reverts commit 3809886.
I see. In that case, I changed them to not default |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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?
Co-authored-by: Seth Axen <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, thanks!
This PR is primarily motivated by an issue where
Quaternion(1) == 1
returnedfalse
. There were two issues at play here.First,
convert(Quaternion,::Real)
andconvert(Quaternion,::Complex)
were never setting the.norm
field of the resulting Quaternion. This meant thatQuaternion(1.0).norm == true
whileconvert(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.