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

[ENH]: investigate more reasonable default for reg param in ProjCommon #35

Open
dengemann opened this issue Nov 7, 2022 · 9 comments
Open

Comments

@dengemann
Copy link
Collaborator

@apmellot has made the discovery that the strange necessity to scale by trace of cov can be avoided when reducing the amount of shrinkage via reg in ProjCommon. This makes intuitively sense and I think we should simply not shrink by default, especially, as we commonly used regularized covariance estimates to begin with and dimensionality reduction has a shrinking effect.

FYI @DavidSabbagh @agramfort

@agramfort
Copy link
Collaborator

The typical way of doing is to have the shrink parameter proportional to the trace of the matrix

@dengemann
Copy link
Collaborator Author

... we could also remove the paramter all together. Why re-implement shrinkage if the user has all the options to estimate robust covariances using OAS, Ledoit-Wolf, etc. ?

@agramfort
Copy link
Collaborator

agramfort commented Nov 7, 2022 via email

@DavidSabbagh
Copy link
Collaborator

DavidSabbagh commented Nov 8, 2022 via email

@DavidSabbagh
Copy link
Collaborator

DavidSabbagh commented Nov 8, 2022 via email

@dengemann
Copy link
Collaborator Author

Now for the Cam-CAN data, Apolline finds that you can avoid the 2nd step by not additionally regulating the covariance in PCA space.
Also note that the trace scaling is part of MNE's CSP / SPoC procedures and is turned off by default (not recommended according to documentation).
I think we should by default try to offer a clean method that does not do too much of correction by default.

@dengemann
Copy link
Collaborator Author

@DavidSabbagh and did you think about it? Meanwhile, @apmellot keeps having good results across all benchmarks using the new settings.

@DavidSabbagh
Copy link
Collaborator

I agree. Let's turn off that normalization by default, while keeping it as an available option.

@dengemann
Copy link
Collaborator Author

this should be addressed now by #51 – let's keep it open to see if we're happy

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants