Code of Conduct
By submitting this report you automatically agree that you've read and accepted the following conditions.
- Support for DQ Robotics is given voluntarily and it's not the developers' role to educate and/or convince anyone of their vision.
- Any possible response and its timeliness will be based on the relevance, accuracy, and politeness of a request and the following discussion.
- If a DQ Robotics member replies, the user must let them know if their response solves their issue or not.
- Any suggestion/advice/request made by anyone, as well intentioned as they might be, might not be incorporated into DQ Robotics.
Bug description
The MATLAB code currently doesn't handle operations between Inf/NaN and dual quaternions. This leads to incorrect results in edge cases.
To Reproduce
- Add a minimal example to concisely illustrate your problem. Otherwise, it is very unlikely that someone will engage with your problem.
- Add the output you had, including error messages.
- Format it using code tags:
Code with line command output
>> x_dq = inv(DQ(0))
x_dq =
0
ans =
NaN
NaN
NaN
NaN
NaN
NaN
NaN
NaN
>> x_double = inv(0)
Warning: Matrix is singular to working precision.
x_double =
Inf
>> x_dq = inv(DQ.E)
x_dq =
0
ans =
NaN
NaN
NaN
NaN
NaN
NaN
NaN
NaN
>> x_dq = DQ.E*NaN
x_dq =
0
ans =
NaN
NaN
NaN
NaN
NaN
NaN
NaN
NaN
>> x_dq = DQ(1)*NaN
x_dq =
0
ans =
NaN
NaN
NaN
NaN
NaN
NaN
NaN
NaN
>> x_dq = DQ.E*Inf
x_dq =
E*(Inf)
ans =
NaN
NaN
NaN
NaN
Inf
NaN
NaN
NaN
>> x_dq = DQ(1)*Inf
x_dq =
Inf
ans =
Inf
NaN
NaN
NaN
NaN
NaN
NaN
NaN
>> Expected behavior
There are two ways we can handle this. One is not to support Inf and NaN, which is a conservative approach and will force users to fix any potential problems through appropriate exceptions. Another option is to support it like MATLAB does, which might create two potential challenges. First, we'll need to implement operations involving Inf and NaN and potentially cascade it to many functions (inv, norm, display, etc.). Second, which for me is even more critical, operations involving Inf and NaN hide underlying numerical problems that quietly propagate into one's code, leading to undesirable behavior that more inexperienced people won't catch.
Expected output
>> x_dq = inv(DQ(0))
x_dq = Inf % or throw an error
>> x_dq = inv(DQ.E)
x_dq = Inf % or throw an error. Note that DQ Robotics assigns NaN to all coefficients instead, which is even weirder.
>> x_dq = DQ.E*NaN
x_dq = DQ.E*NaN % or throw an error. Note that DQ Robotics assigns NaN to *all* coefficients instead of only the fifth coefficient.
>> x_dq = DQ(1)*NaN
x_dq = NaN % or throw an error. Note that DQ Robotics assigns NaN to *all* coefficients instead of only the first coefficient.
>> x_dq = DQ.E*Inf
x_dq = E*(Inf) % or throw an error. Note that DQ Robotics displays the dual quaternion correctly, but assigns NaN to *all* coefficients but the fifth, which is correctly assigned to Inf.
>> x_dq = DQ(1)*Inf
x_dq = Inf % or throw an error. Note that DQ Robotics displays the dual quaternion correctly, but assigns NaN to *all* coefficients but the first, which is correctly assigned to Inf.
Environment:
- OS: MacOS Sequoia 15.6
- dqrobotics version: master branch (commit: 6b39262)
- MATLAB version: R2023a
Additional context
We must see if similar issues happen in other languages. This might be affecting the numerical accuracy when dealing with algorithms that involve multiple iterations. I'm currently observing some issues with $x_{k}=x_{k-1}(x_{k-1}^{\ast}x_{\mathrm{new}})^{\left( \alpha\right) }$, where after many iterations the norm stops being one. This might also have some relation to #68.
Code of Conduct
By submitting this report you automatically agree that you've read and accepted the following conditions.
Bug description
The MATLAB code currently doesn't handle operations between Inf/NaN and dual quaternions. This leads to incorrect results in edge cases.
To Reproduce
Code with line command output
Expected behavior
There are two ways we can handle this. One is not to support Inf and NaN, which is a conservative approach and will force users to fix any potential problems through appropriate exceptions. Another option is to support it like MATLAB does, which might create two potential challenges. First, we'll need to implement operations involving Inf and NaN and potentially cascade it to many functions (
inv,norm,display, etc.). Second, which for me is even more critical, operations involving Inf and NaN hide underlying numerical problems that quietly propagate into one's code, leading to undesirable behavior that more inexperienced people won't catch.Expected output
Environment:
Additional context
We must see if similar issues happen in other languages. This might be affecting the numerical accuracy when dealing with algorithms that involve multiple iterations. I'm currently observing some issues with$x_{k}=x_{k-1}(x_{k-1}^{\ast}x_{\mathrm{new}})^{\left( \alpha\right) }$ , where after many iterations the norm stops being one. This might also have some relation to #68.