fix: sanity_check usage when n_bkps is not explicitly specified #190
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
In cases where the
n_bkps
is not explicitly specified, currentsanity_check()
usage does not reflect how it should be used. Indeed, in some cases, finding 0n_bkps
is a fine results. Therefore, we should not make the assumption that there is at least 1 break point in the following cases :Binseg
: if then_bkps
is not specified atpredict()
time, then allow for 0 break pointsBottomUp
: if then_bkps
is not specified atpredict()
time, then allow for 0 break pointsWindow
: if then_bkps
is not specified atpredict()
time, then allow for 0 break pointsPelt
: allow for 0 break pointsThere is one special case :
KernelCPD
: our C implementation make the assumption that when it is called, we are looking for at least 1 break point. Therefore, for this class, even if "in theory" for the Pelt option allows for 0 break point, we keep thesanity_checks()
usage to reflect implementation choices.Tests are also modified accordingly.
closes #188