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

Update kolmogorov quantile newton ub to 1 #1002

Merged

Conversation

ryanelandt
Copy link
Contributor

This is chunk 1 for #1000

Change search bound:
This PR changes the kolmogorov_smirnov quantile search upper bound from max_value<RealType>() to RealType(1). Quantiles appear to be defined on [0,1].

Simplify Newton Solver
The Newton solver previously had to evaluate the kolmogorov functor at max_value<RealType>() / 2 during bisection, which would cause the program to hang. Newton bisection logic added to prevent this evaluation from happening. With the quantile upper bound changed to 1, this logic is no longer required.

}
else
delta = shift;
delta = (delta > 0) ? (result - min) / 2 : (result - max) / 2;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wait, we may need to protect against huge jumps in other people's code right? We only know that this is now unnecessary for Komogorov-Smirnov.

Copy link
Contributor Author

@ryanelandt ryanelandt Jul 25, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I looked into this. Here is the history...

#145 @jzmaddock opened an issue where skew-normal quantiles return non-finite values. This issue occurs because the min/max bounds for the 1D Newton search problem are -Inf/+Inf. Attempting to bisect the search point at either ends gets one stuck at either -Inf/+Inf.
91c193d @jzmaddock Fixed #145 by adding an early version of huge step protection. A test was also added to test_roots to prevent possible regressions.
3ab69d0 The test in test_roots was removed as part of adding the complex Newton solver, possibly due to a merge conflict oversight.
#422 @evanmiller added the kolmogorov-smirnov distribution. The min/max bounds for the 1D Newton search problem are 0/max_value(). This new functionality requires huge step protection because evaluating the functor at large values causes the program to hang.

Copy link
Contributor Author

@ryanelandt ryanelandt Jul 25, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Huge step protection seems to cover up issues with Newton search bounds for quantile problems.

This PR attempts to resolve this with the following steps:

  1. Change the skew_normal quantile search to go from -max_value/+max_value instead of -Inf/+Inf.
  2. Change the upper search bound of the kolmogorov-smirov distribution to RealType(1). This fixes the hang issue, and causes no test issues, I don't know if it is right though.
  3. Add the test that the skew-normal quantile is finite back in

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that changing the bounds to [0, 1] is correct per this table of sample values http://www.matf.bg.ac.rs/p/files/69-[Michael_J_Panik]_Advanced_Statistics_from_an_Elem(b-ok.xyz)-776-779.pdf since it doesn't look like we support D_n,m.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Apologies for being late to the party... it'll still be another week at least till I have any time.

Removing the large step protection is probably a bad idea, but I would have to go searching for a test case to tell you why ;)

These root finders are rather problematic to test because they are fundamentally quite resilient even to bugs/errors in their code because of the way they work. I worry about that, but I also want them to be resilient!

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Removing the large step protection is probably a bad idea, but I would have to go searching for a test case to tell you why ;)

There's a test case that requires it in the current code-base, although it isn't causing a test failure. Discussed further here: #1000 (comment).

@ryanelandt ryanelandt mentioned this pull request Jul 25, 2023
@mborland mborland merged commit c62682b into boostorg:develop Jul 31, 2023
56 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants