-
Notifications
You must be signed in to change notification settings - Fork 38
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
Add more tests to strax #359
Conversation
…tion/strax into loop_plugin_multioutput
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.
Looks mostly fine just some minor comments and suggestions. Took me a while to understand test_loop_plugin, but looks fine too.
@@ -3,7 +3,6 @@ | |||
import tempfile | |||
import os | |||
import os.path as osp | |||
|
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.
?
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.
there probably was an import statement during some point of the live time of this PR
tests/test_loop_plugins.py
Outdated
:param chunks: list op numpy arrays to modify. Here we will drop some of the fields randomly | ||
:return: list of chunks | ||
Drop some of the data in the chunk | ||
:param chunk: list op numpy arrays to modify. Here we will drop some |
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.
typo op -> of?
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.
Just to be sure, "chunk" refers here to chunk.data
or must I convert a chunk object first into an array?
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.
yeah, it's the chunk.data, also see the type specification in the function definition
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.
let me smooth out the docstring a little
tests/test_peak_properties.py
Outdated
|
||
# Fill the peaks with random length data | ||
for p in peaks: | ||
length = np.random.randint(0, data_length) |
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.
I am wondering if it would not be nicer to have this already in the hypothesis itself for tracking reasons. You can also create a list of integers.
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.
Can do but as I don't see the how this would affect thinks I consider it unlikely that we ever have to replicate on this specific point. Therefore, I will keep it as it is.
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.
Turns out that this was a good comment though. See #363. Someday will rewrite this test in a similar way!
tests/test_peak_properties.py
Outdated
p['data'] = wf | ||
|
||
for i in range(length, len(wf)): | ||
# Set all the out of length data to zero | ||
wf[i] = 0. |
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.
p['data'][:data_length] = wf
does not work?
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.
nope, I also found that strange. Perhaps my syntax was off or its because it's unjitted but yeah
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.
Hmm okay this odd, because I was not sure and so I tried the following in a notebook before I made the comment
peaks = np.zeros(2, dtype=strax.peak_dtype())
for p in peaks:
length = int(np.random.uniform(0, 20))
data = np.random.uniform(0, 20, length)
p['data'][:length] = data
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.
Ok, so the Perhaps my syntax was off
seems quite likely. Will change, thanks Daniel!
tests/test_peak_properties.py
Outdated
peaks = np.zeros(peak_length, dtype=dtype) | ||
dt = 1 | ||
peaks['time'] = np.arange(peak_length)*dt | ||
peaks['dt'][:] = dt |
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.
peaks['dt'] = dt
should work
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.
sure
tests/test_peak_properties.py
Outdated
p['data'] = wf | ||
|
||
for i in range(length, len(wf)): | ||
# Set all the out of length data to zero | ||
wf[i] = 0. |
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.
See comment above. In general I am wondering if it would not be easier to simply merge this test with the previous one. A lot of duplication in here.
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.
Not impossible but I like the fact that the first test does test something whereon the second test is build.
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.
But this would be also the case if you join them no? But you would just initialize everything once and have less copy-paste code.
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.
OK, will change the setup of the random peaks to a different function, you are right that there is some unnecessary duplication. My reasoning is that I don't mind that much if the tests are sometimes a little rough/slightly duplicate, it's already tedious enough to write them while being quite unrewarding ;).
But this would be also the case if you join them no
So the failure would be a little clearer because you split it over multiple functions with the name of what is being tested.
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.
it's already tedious enough to write them while being quite unrewarding ;).
Yes I know :D I feel with you. But it is our task to gently bully one another for a cleaner code.
OK, will change the setup of the random peaks to a different function,
So the failure would be a little clearer because you split it over multiple functions with the name of what is being tested.
Okay nice, in this way we get both.
if np.sum(peaks['area'] > 0) > 10: | ||
mess = ("Highly unlikely that from at least 10 positive area peaks " | ||
"none were able to compute the width") | ||
assert np.any(peaks['width'] != pre_peaks['width']), mess |
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.
The test is very vague, but I can see the difficulty. Maybe we should add a simple unity test like:
data = np.ones(100)
*compute widths in 10% steps*
*check widths*
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.
It's quite simple right? You just check that the widths were computed at all and not all 0.
@@ -39,3 +52,7 @@ def test_LocalMinimumSplitter(): | |||
assert len(my_splits) <= int(len(w) / 2) + 1 | |||
assert min(my_splits[:, 0]) == NO_MORE_SPLITS | |||
assert my_splits[-1, 0] == NO_MORE_SPLITS | |||
|
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.
L49, L50 would not >=
work?
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.
there has to be at least one NO_MORE_SPLITS right. You can also not split on the last entry.
EDIT: Oh wait the lines you are mentioning are different from the ones I'm seeing. But yeah, I tend to agree (although not really part of this PR but originally written by Tim: https://github.com/AxFoundation/strax/pull/267/files).
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.
Yes, sorry there was no other way to comment on this and it just stroke my eye.
@@ -112,12 +55,8 @@ def _loop_test_inner(big_data, nchunks, target='added_thing', force_value_error= | |||
|
|||
_dtype = big_data.dtype | |||
|
|||
# TODO smarter test. I want to drop some random data from the |
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.
L39 typo to -> two
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.
thanks
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.
Okay looks good.
What is the problem / what does the code in this PR do
Fix a slight mistake in #357 concerning the testing.
Further I've added some other tests while I was waiting on some computations to finish.