Skip to content
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

Improvements of numerical stability #123

Open
Fubini2 opened this issue May 11, 2022 · 0 comments
Open

Improvements of numerical stability #123

Fubini2 opened this issue May 11, 2022 · 0 comments
Labels
enhancement New feature or request

Comments

@Fubini2
Copy link

Fubini2 commented May 11, 2022

Dear @pantor,

we committed a new version https://github.com/Fubini2/ruckig/network to our fork including some numerical improvements we have been working on in our use case, see #72 and #71. These improvements enabled us to not only use your code with the addition of the final acceleration phase, but also allowed us to use the code without the need to scale inputs any more. Maybe you could think about adding those improvements to the main development line. So for now, let me add a few explanations on the main changes we did and the reasons why we did them. Feel free to ask any question about it:

  1. roots.hpp: For our use case the epsilons were much too high.
    We found out the main cases of your root solver works quite well, while the edge cases often failed due to numerical issues. By decreasing the epsilons we now almost always calculate the solution using the main case.
  2. brake.cpp: Adding or subtracting eps here on some values added some numerical uncertainty to otherwise perfectly fine values that hindered decision making on whether a solution is good or bad later on. So we reduced accuracy in the decision making process but not in the actual values that later on are used to integrate the solution.
  3. Some comparisons were numerically unstable so we added a "Unit in the last place (ULPS) https://en.wikipedia.org/wiki/Unit_in_the_last_place" based comparison method for these data (robust_*_check(...)).
  4. position.hpp: Having done the above alterations we have seen that sometimes a UDDU and a DUUD profile work because they are both inside the tolerance bounds which later on generated an error inside your code. So we added some code to specifically filter out one of those both case using the profileIsGreat method.

Fubini2

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants