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

Channel adjacency improvements #12292

Open
mscheltienne opened this issue Dec 12, 2023 · 1 comment · May be fixed by #12293
Open

Channel adjacency improvements #12292

mscheltienne opened this issue Dec 12, 2023 · 1 comment · May be fixed by #12293
Labels

Comments

@mscheltienne
Copy link
Member

mscheltienne commented Dec 12, 2023

Proposed documentation enhancement

The docstring of the picks argument in read_ch_adjacency is wrong as there is no info provided to this function.

Also, find_ch_adjacency could benefit from an extra argument similar to pick in read_ch_adjacency to select channels to include in the adjacency matrix. I see 2 options forward:

  • (1) Keep ch_type and add exclude=() which can be set to exclude="bads"
  • (2) Deprecate ch_type in favor of the traditional picks argument, with an adapted docstring mentioning that the channel selection provided must yield a single channel type (+ check and appropriate error message)

I'm in favor of (2) as it offers more flexibility to find_ch_adjacency.

Correspond to this forum post: https://mne.discourse.group/t/find-ch-adjacency-not-accounting-for-bad-channels/7968/

@larsoner
Copy link
Member

Given ch_type is in second position and we easily can do something like:

def find_ch_adjacency(info, picks, *, ch_type=None):
    if ch_type is not None:
        warn(...)
        picks = ch_type

that will avoid breaking code for some folks, I'm in favor of (2)

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

Successfully merging a pull request may close this issue.

2 participants