Skip to content
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

Make MA-PCA criteria curves more accessible to users #834

Closed
handwerkerd opened this issue Jan 17, 2022 · 3 comments · Fixed by #839
Closed

Make MA-PCA criteria curves more accessible to users #834

handwerkerd opened this issue Jan 17, 2022 · 3 comments · Fixed by #839
Assignees
Labels
decomposition issues related to decomposition methods effort: low Theoretically less than a day's work enhancement issues describing possible enhancements to the project impact: low Improving code/documentation cleanliness/clarity, not function priority: medium Should get addressed soon

Comments

@handwerkerd
Copy link
Member

Summary

The number of PCA components is defined using one of several methods. A recent neurostars question and an issue I've been examining would have been easier to answer if the criteria curves used to calculate the number of components were more accessible. I propose outputting these curves either by default or when the --verbose option is used.

Next Steps

@handwerkerd handwerkerd added enhancement issues describing possible enhancements to the project decomposition issues related to decomposition methods priority: medium Should get addressed soon effort: low Theoretically less than a day's work impact: low Improving code/documentation cleanliness/clarity, not function labels Jan 17, 2022
@eurunuela
Copy link
Collaborator

Have that PR also return either the full PCA object or the three criteria curves so that tedana can access that information

Do you think adding a "selection" array or dictionary would be enough? It could be something like mapca.selection_ = {"aic": 67, "kic": 56, "mdl": 36}.

Add code after this line to save the numbers in the criteria curves for aic, kic, and mdl.

I personally think we should save the plot and log the selection numbers.

@tsalo
Copy link
Member

tsalo commented Jan 18, 2022

I think we should leverage the "classification" and "rationale" columns of the PCA component table, and retain the full PCA mixing matrix. When we shift from "rationale" to "tags", we can also add "aic_accepted", "kic_accepted", and "mdl_accepted" tags, right?

We could of course also add AIC, KIC, and MDL to the PCA table's metrics.

@handwerkerd
Copy link
Member Author

There are a bunch of single values that should be saved in a clear location. I'd add % variance explained by the PCA to the three selection criteria.
FWIW, the decistion tree modularization has a dictionary & saved file called cross_component_metrics I could see making a new file called PCA_cross_component_metrics now and then the decision tree's file would become ICA_cross_component_metrics

I also think we should be saving the curves and not just the aic/kic/mdl thresholds. Those curves were important for diagnosing issues, so if we're saving something, they should be accessible.

The full PCA mixing matrix would be a fairly large file. If we're saying it, it should definitely only be saved with the --verbose option.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
decomposition issues related to decomposition methods effort: low Theoretically less than a day's work enhancement issues describing possible enhancements to the project impact: low Improving code/documentation cleanliness/clarity, not function priority: medium Should get addressed soon
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants