mne-tools / mne-connectivity

Connectivity algorithms that leverage the MNE-Python API.
https://mne.tools/mne-connectivity/dev/index.html
BSD 3-Clause "New" or "Revised" License
68 stars 34 forks source link

Consolidation of methods with "indices" vs not #11

Open adam2392 opened 3 years ago

adam2392 commented 3 years ago

Because some "connectivity" functions are defined as bivariate functions between two sets of signals, we can allow "indices" argument in various functions.

This should probably be well-documented as showing up as "nans" in a connectivity container?

britta-wstnr commented 3 years ago

Not sure I understand what you mean. Do you mean for specifying e.g. which channels or source points should be considered out of the full list a data set might have? That indeed would raise interesting questions for the output and for plotting.

adam2392 commented 3 years ago

There are methods such as spectral_connectivity, where one can pass in indices = ([1, 2], [0]) for example where they only compute connectivity between node 1/0 and 2/0.

This raises issues for downstream storage in a container and plotting. The way I solve it is by keeping track of indices and keeping the rest as nans. This runs into "storage" concerns if the arrays are big enough. In general though I was thinking we should probably keep track of "what can take in this extra parameter" vs not.

drammock commented 3 years ago

The way I solve it is by keeping track of indices and keeping the rest as nans. This runs into "storage" concerns if the arrays are big enough.

sounds like a use case for scipy.sparse if memory turns out to be constrained

adam2392 commented 3 years ago

envelope_correlation seems like a function we can also add "indices" for.