-
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
RuntimeWarning: divide by zero encountered in divide #1006
Comments
Hmmm, this seems strange. The error is coming from line 2257:
It would be good to dig into what the inputs and outputs are. It suggests that perhaps:
isn't capturing/processing the right constant subsequences? |
Right! I will take a closer look (Also, I want to see what happens to |
Okay. I think this works! (Probably I made a mistake before).
I can see that this is happening when we have a subsequence with all non-finite values. For example, running the following script throws the
we are mixing two things in the line The reason that we did not get any failure in the unit testing of To avoid similar issue in the future, we may at least throw a warning when
If we decide to go with this, then we may need to re-think the usage of |
What is the logic behind swapping the two lines? There's a reason why it is in its current order and I think the current order matters! So, I am against swapping as it will change the overall/existing logic
Sorry, I'm still not understanding the problem and how this is caused by |
Part 1
(I noticed that in ostinato, the story is a bit different. I explained it in the This logic comes from the answer to this question: "what should one expect from Example:
Running code above gives:
Another example:
Part 2
In ostinato, we can see the following flow (This is a bit different than Lines 2248 to 2260 in 0107d39
(Side Note: In this case, In line Example:
Here, I also see an extra warning:
Part 3As mentioned in Part 2, Lines 239 to 276 in 0107d39
This is because the corresponding value of such subsequence in Lines 1093 to 1106 in 0107d39
So, we will eventually end up with correct value for Example: Running the following script
gives:
However, the matrix profile value should have been |
I think this logic is aligned with computing Lines 2248 to 2260 in 0107d39
as the line In Lines 2135 to 2142 in 0107d39
I feel it make sense as long as we do all these relevant computation next to each other (and provide clear description in the docstring / comment) |
The more I read this, the more I disagree. While it might seem "smart" to do it this way, it is polluting the meaning of
If the issue is that
This way Then, all of the I haven't tested this but it captures the spirit of what I am hoping for
Yeah, I don't think I agree that "this is the logic". With the exception of converting non-finite numbers into |
So, in that case: (i) In Line 2256 in 3077d0d
with
to avoid getting warning that comes from the line Note: This is to avoid getting warning in (ii) should we improve the docstring of Lines 2232 to 2246 in 3077d0d
by saying something like this:
? (or, is that too much?) Regarding Part 2 and Part 3 of my previous comment
Got the point. Note1: If we only implement
(in Note 2:
The tests in Lines 239 to 246 in 3077d0d
(that is computed in Note 2-WARNINGIn the same function Line 259 in 3077d0d
This is a njit-decorated function with
we may try to revise the |
So, I like the spirit of this and I think it is headed in the right direction. However, it seems implicit/dangerous to set all
This way, it is explicitly clear WHEN Σ_T needs to be set to
Again, if we are explicit in our code about WHY we are setting something to
for which |
I think it's better to say ". Each subsequence in
Umm, I think you mean "T_subseq_isconstant[i] is automatically set to |
Cool! I'd like to see the final code for this.
I don't like this. I think we should agree that the private functions should already be preprocessed. We may need to re-think things more in order to ensure consistency |
Have you added the test above to the unit tests? |
There is no more reason other than those two. I agree. Being explicit helps us to know for what subsequences exactly we are setting the standard deviation to
Right! My bad 😅
Right. If we decide to pass
So, what I meant was that changing the code does not result in failing current tests. Will add new tests. |
Running the following script
Gives:
I took a look at the code:
stumpy/stumpy/core.py
Lines 2248 to 2260 in e7bb2b8
and tried to swap lines 2252 and 2253, but that did not work.
Also:
If I disable JIT, I get an extra warning, saying:
The text was updated successfully, but these errors were encountered: