-
Notifications
You must be signed in to change notification settings - Fork 323
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
Fix #695 Add "subseq_isconstant" param to API #789
Fix #695 Add "subseq_isconstant" param to API #789
Conversation
Codecov ReportPatch coverage:
📣 This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more Additional details and impacted files@@ Coverage Diff @@
## main #789 +/- ##
========================================
Coverage 99.24% 99.25%
========================================
Files 82 82
Lines 12974 13121 +147
========================================
+ Hits 12876 13023 +147
Misses 98 98
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. ☔ View full report in Codecov by Sentry. |
@seanlaw
|
What about |
Well... I haven't explored all modules yet but we should defintely check them. I also need to check the ones I mentioned in my previous comment again to make sure the implementation is doable/ reasonable. For instance: I have some difficulty in understanding how users can get benefit from this feature when data is updated dynamically. In What about PAN matrix profile? I haven't studied its module yet but it seems it computes matrix profile for different window length. So, in that case, I think we should avoid allowing user to insert their own "subseq_isconstant" array for just one window size. Or, we should allow them to provide this array for each window size. I will try to explore modules one by one to see if we can add this new support for them. Please let me know if you have any suggestion. |
So, I'm wondering if we could do something like:
And then, in a function like
I haven't thought this through and it is still somewhat convoluted but some variation of this might work after we clean it up. It should even be usable for Again, just a soft proposal for you to consider. |
This actually sounds great! We can also let user know that subsequences with at least one nan or inf will be treated as "not constant" regardless of the provided custom function. (Otherwise, we need to modify |
5f6704d
to
5be22a7
Compare
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.
Added one minor suggestion. Also, I wonder if it makes sense to break this up into smaller individual PRs rather than one giant one? The current size of this PR is okay but maybe we merge this one when it is ready and then add other files in a separate PR?
According to our experience in top-k PR, I think what you are suggesting is reasonable. I checked out the changed files and I think this PR is ready. We already added the param to |
[Update] |
@NimaSarajpoor It looks like we are missing some code coverage:
Note that even though these are are |
I really need to understand the importance of checking code coverage by heart :) |
def test_find_incompatible_args(): | ||
# case1: having exact required argument | ||
def func_case1(x, y): | ||
return |
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 function and other functions below it are designed to test the functionality of core._find_incompatible_args
. However, since we do not call these functions (right?), these functions are skipped according to the result shown in code coverage. Any suggestion @seanlaw ?
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.
@seanlaw
FYI: To fix code coverage, I added # pragma: no cover
here and for the next few functions.
First, I recommend running the tests locally first for non-trivial PRs. Having said that, I'm going to add something to our coverage reporting to force it to fail if the coverage is below 100%. Hopefully, that'll help. I should've done it a long time ago |
Right! Need to keep that in mind!
Cool!! I think that would be a great idea! |
@NimaSarajpoor I just pushed a new commit that I think/hope will cause a failure. Would you mind pulling it into this branch? |
That was quick :) I will update my branch. |
Please pull the latest commit (the last one wasn't enough). |
@seanlaw
I am going to push the commits... |
We got error. That is good. I will wait till you handle the error occured in your last commit (You may want to see this: nedbat/coveragepy#198) |
It should be fixed now. |
@seanlaw |
@NimaSarajpoor Everything looks good here. Merging now. Thanks! |
No description provided.