-
Notifications
You must be signed in to change notification settings - Fork 62
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
[MRG] Filter Report #235
base: main
Are you sure you want to change the base?
[MRG] Filter Report #235
Conversation
Hey @ryanhammonds - what are your thoughts on making this collect the info into a string that can be printed, as you have now, or saved out for later? Something like what FOOOF does for reports? I'm thinking for the context of a script, or if there was a filter node in NDSPflow. One might want to keep a record of the filter details, but printing to console wouldn't necessarily be the easiest way to do so, and saving out the report might be useful. What do you think? If this would be super annoying, then it's probably not worth it, but if you think it wouldn't take too long, then it might be useful. |
Hi @TomDonoghue, I've added a |
Also, tests are failing here due to an unrelated issue I think - nothing has changed in Edit: I fixed the bug in master. a23a192 was needed to pass the travis 'branch' build (since this branch was built on an older master). a23a192 should be dropped when merging since the travis 'Pull Request' build was passing at 6a5695e and this branch will be delete after merge. The changes for a23a192 already exists in master and github doesn't render a diff. |
221b8a9
to
6a5695e
Compare
@ryanhammonds - okay, so I did a review, and left specific comments. Thanks for your work on this - I know this stuff on the nitty-gritty of filter details can be tricky / annoying! More broadly than the individual comments, I think we might want a slightly different approach here. Some thoughts:
Or, short version: let's keep If this does sound promising, in terms of creating more of a formatted string to save out in combo with the plots, these might be useful from spectral param: |
91eaf44
to
b98d669
Compare
@TomDonoghue I restored the functionality of |
I met with Brad yesterday to discuss some of the things I am working on and he voted to keep |
So what will 'verbose' do then? It's not clear to me it adds any functionality...? |
So yeh, in terms of what Anyways - sorry for the confusion on this one - referring back to your previous comment, I also have in mind that this should be like So - what still needs doing here? |
So the plots are only plotted in my example because Not a big deal to me either way so no need to go on about this. Verbose has been dropped already. With the exception of the one unresolved comment, it should be how you wanted and ready to merge. Feel free to direct push any changes you want or to close. |
a04e503
to
bc4202f
Compare
bc4202f
to
993893c
Compare
9353581
to
555dd59
Compare
Related to #229 and #139. This PR adds a
verbose
arg tofilter_signal
,filter_signal_fir
andfilter_signal_iir
that prints out the filter information (suggested in Widmann et al 2015). This includes:The previous
print_transitions
argument functions the same as the verbose arg now (i.e.verbose=np.any([print_transitions, verbose])
). I can fully deprecate this arg or modify it to only print transitions.I'm not sure if the last three bullets are determined correctly (they probably aren't). I'll have to revisit to sort this out.