-
Notifications
You must be signed in to change notification settings - Fork 15
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
[ENH] Moredocs and experiment with api implementation #31
Conversation
Codecov Report
@@ Coverage Diff @@
## main #31 +/- ##
==========================================
+ Coverage 97.44% 97.48% +0.04%
==========================================
Files 8 9 +1
Lines 430 437 +7
==========================================
+ Hits 419 426 +7
Misses 11 11
Continue to review full report at Codecov.
|
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.
One comment, otherwise LGTM
component_dict = { | ||
"y_pred_proba": labels_pred_proba, | ||
"y_pred": labels_pred, | ||
"labels": labels, | ||
} | ||
return component_dict |
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.
Any reason for nesting the output in a dictionary? Can't we directly have return y_pred_proba, y_pred, labels
(in this order or another)?
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.
No real preference.
I only did this to make it super explicit and limit the number of return variables / make it a one-liner to convert to a Dataframe. Would you prefer the 3 tuple return instead?
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.
No strong preference either, but you can't convert this to a DataFrame that easily either since labels_pred_proba
is a 2D 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.
Ah fair. Hmm now that I think about it more I do prefer in general single return arguments, but I'm also unsure if this is optimal here... I'll leave this open for now and we can always change it.
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 like the idea of simple conversion to DataFrame for the user (of course not on our end, let's not have pandas as a dependency just for that). With that in mind, I see 2 individual DataFrame in the proposed output:
idx | labels | y_pred |
---|---|---|
0 | Eye | 0.89 |
1 | Brain | 0.67 |
... | ... | ... |
and:
idx | Brain | Muscle | Eye | Heart | Line Noise | Channel Noise | Other |
---|---|---|---|---|---|---|---|
0 | 0.2 | 0.89 | 0.1 | 0.05 | 0.03 | 0.07 | 0.08 |
1 | 0.03 | 0.67 | 0.06 | 0.04 | 0.1 | 0.3 | 0.09 |
... | ... | ... | ... | ... | ... | ... | ... |
n_comp | 0.3 | 0.23 | 0.43 | 0.22 | 0.11 | 0.08 | 0.7 |
So how about 2 outputs: return dict(labels=labels, y_pred=labels_pred), {value: labels_pred_proba[:, k] for k, value in ICLABEL_NUMERICAL_TO_STRING.items()}
.
IMO, for what needs to be stored in the mne ICA instance, we do not need the y_pred
, but only the labels
and the second dict.
With this solution, you can get the 'raw' numpy array of probabilities with mne_icalabel.iclabel.iclabel_label_compoments
or dictionaries ready to be transformed to DataFrames with mne_icalabel.label_components
.
WDYT?
Nice, I also added rendering docs directly with a circleCI redirect: |
I will merge this once the CI complete. |
PR Description
Addresses #5 and #19
Merge checklist
Maintainer, please confirm the following before merging: