-
Notifications
You must be signed in to change notification settings - Fork 19
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 main workflow of phys2denoise #17
Conversation
Co-authored-by: @62442katieb <[email protected]>
We're ready for review! In any case, please have a look! @tsalo @eurunuela @62442katieb, let's see if we can merge this soon(ish)! |
Also let me be clear: this is a little, small, first step toward having something that given an input returns an output that makes sense (together with the other bunch of PRs). Nowhere near the state of development we want to get to though! For this reason I'm using the minormod-breaking label. We're still in alpha after all. |
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.
LGTM! Thanks @smoia !
Oh, I almost forgot. You should update the label if you think this is a majormod (I think it is). |
Yup, you're right in that this is a majormod, however I thought that the general approach we wanted to follow (phys2bids#192) was not to go in the 1.0 + versioning until we leave beta stage. That's why I'm adopting the minormod-breaking label (after the suggestions in phys2bids#192) |
Sounds good! It's also good that we have it written on this thread for future reference. |
phys2denoise.py
Outdated
**args) | ||
elif metrics == 'retroicor_resp': | ||
args = select_input_args(compute_retroicor_regressors, metric_args) | ||
args['resp'] = True |
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.
Doesn't make more sense to modify this so we don't have two if conditions, one here and another one in the retroicor 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.
What do you mean @vinferrer ? The two if
s do different things (Or you mean to recode the three functions in retroicor intotwo? But then there's quite a lot of lines that are common...)
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, after seeing that you don't input the metrics argument directly, why don't you put this line inside select_input_args
I think you can reduce this if statement at least, another thing is that instead of creating the dictionary entry args['card'] = True
when metrics == 'retroicor_card'
you could use directly the metrics == 'retroicor_card'
inside compute_retroicor_regressors
. Do you follow? or should I do suggestions in both PR's?
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 think we can avoid an extra if statement
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 mean, you have a function called select_input_args
I would include the type of metric detection inside of this function rather than in the main workflow
phys2denoise.py
Outdated
else: | ||
args = select_input_args(metric, metric_args) | ||
print_metric_call(metric, args) | ||
regr[f'{metric}'] = metric(physio, **args) |
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.
Also, what function is this?
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.
Which one?
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 a couple of questions/comments. I imagine we'll need to resolve some conflicts between the parameter names in this PR and those in #19, but that's not a big deal and shouldn't slow us down.
🚀 PR was released in |
Closes #14
Proposed Changes
Change Type
bugfix
(+0.0.1)minor
(+0.1.0)major
(+1.0.0)refactoring
(no version update)test
(no version update)infrastructure
(no version update)documentation
(no version update)other
Checklist before review