Regularization parameter for current source density

💬 Support & Discussions
,
1

In the estimation of current source density, MNE-Python uses a stiffness and a regularization parameter. Whereas the stiffness parameter is described in the (Perrin et al., 1989) paper of CSD, I have not seen any reference to regularization. Is the addition of regularization is something specific to MNE-Python or is it follow some previously published work?

It seems to me as the regularization parameter can be used to control the spatial scale of the information in the CSD but I am tempted to set the regularization to 0 to use the “vanilla” implementation of CSD. However, since MNE-Python default is not 0, I imagine the default value (10^-5) has been validated and found to be optimal in some regard. If such validation exists (aside from Transform EEG data using current source density (CSD) — MNE 0.23.dev0 documentation), it would be great to know where it is published.

2

Hi Christian,

I am not sure if I misunderstand your question, but regularisation / stiffness has been part of the original CSD implementation, see e.g. here CSD Toolbox - Tutorial
This should be documented in the papers listed as references on the website CSD toolbox.

Hope that helps + best wishes,
Denis

3

Yes, that is very useful. I did not know that it was a port of this toolbox. Thank you Denis.

Christian

4

@Denis In the CSD toolbox, the default parameterization is lamba=1e-5 whereas in MNE it is lambda2=1e-5. My understanding was that lambda2 in MNE was standing for “the square of lambda”. Is there a real discrepancy between the default values for these two toolboxes or is that a typo kind of error and MNE actually uses lambda=1e-5 and just misnamed the argument to the mne.preprocessing. compute_current_source_density method? Or maybe my understanding is at fault here?

5

The numbers are the same no? Or is there some difference in behavior? Note that lambda is a reserved name in Python (anonymous function). The parameter is not directly related to the lambda2 in the MNE inverse solution, at least not as far as I al aware of.

6

OK. I get from your answer that the name lambda2 maps mathematically to lambda and not lambda**2. I think that the choice of name is confusing (giving that elsewhere in MNE the name lambda2 maps to lambda**2) and that the issue with lambda being a keyword could have dealt with using a less confusing name (e.g., lambda_), but thank you for clarifying this issue. I’ll correct my manuscript accordingly.

7

to avoid conflict with lambda from python a common choice is to use lambd or reg

if it’s called lambda2 and it’s not lambda**2 than it’s not consistent with MNE apply_inverse and we
should consider fixing this.

Alex

1 Like
8

Yes, we should probably consider changing the name. That it can lead to a misunderstanding propagating into a manuscript is worrisome.