mne-tools / mne-tools/mne-python

Drop log handling in sliced epochs not intuitive

Open
#9,726 7 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

BUG
Dominant language
Python
Stars
3.5k
Forks
1.6k
Avg merge
1d 6h
Merged PRs (30d)
100

Description

Describe the bug

Using drop_log_stats() or drop_log is unintuitive when working with sliced epochs.

Steps to reproduce

MWE

import mne
import numpy as np

np.random.seed(10)
n_epochs, n_channels, n_timepoints = 10, 4, 21
ch_names = [f"ch_{i}" for i in range(n_channels)]
fake_data = 1e-6*np.random.random((n_epochs, n_channels, n_timepoints))

# Have the first three epochs exceed minmax in one channel
fake_data[0:3, 1, 0] = 200e-6

info = mne.create_info(ch_names=ch_names, sfreq=40)
epo = mne.EpochsArray(fake_data, info)
# This should drop the first three epochs
epo.drop_bad(reject=dict(misc=100e-6))

# Prints 30% as expected
print(f"I expect 30% and am: {epo.drop_log_stats()}%")

# select only the last epoch
subepos = epo[-1:]
# Prints 75%
print(f"I expect 0% or maybe 30% but am: {subepos.drop_log_stats()}")

# Drop log contains IGNORED only for events that were not dropped initially
print(subepos.drop_log)
# Output is:
# (('ch_1',), ('ch_1',), ('ch_1',), ('IGNORED',), ('IGNORED',), ('IGNORED',), ('IGNORED',), ('IGNORED',), ('IGNORED',), ())
Expected results

I would either expect the drop log stats to know the initial ratio of drops, i.e. 30%, or after slicing report only the dropped epochs in the slice, i.e. 0%. However, calculating the latter is hard for non-trivial drop/slice combinations.

Actual results

MNE remembers how many epochs were dropped initially, then ignores the epochs marked as IGNORED and calculates the drop log stats to be 75%, as 3 were dropped and the slice contains 1 non-dropped epoch.

I suspect that when doing slices of epochs, the __getitem__ implementation only inserts ('IGNORED') in the drop log when there is no entry yet.

Additional information
Platform:      Linux-5.11.0-34-generic-x86_64-with-glibc2.29
Python:        3.8.10 (default, Jun  2 2021, 10:49:15)  [GCC 9.4.0]
Executable:    /home/jan/dev/python/spot/spot_venv/bin/python
CPU:           x86_64: 8 cores
Memory:        Unavailable (requires "psutil" package)
mne:           0.24.dev0
numpy:         1.21.2 {blas=openblas, lapack=openblas}
scipy:         1.7.1
matplotlib:    3.4.3 {backend=module://backend_interagg}
sklearn:       0.24.2
numba:         Not found
nibabel:       3.2.1
nilearn:       Not found
dipy:          Not found
cupy:          Not found
pandas:        1.3.2
mayavi:        Not found
pyvista:       Not found
vtk:           Not found

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reproducing the MWE, then trace Epochs.getitem and the drop_log_stats() and drop_log behavior for sliced epochs. The expected semantics need to be settled between initial-drop statistics and slice-only statistics; done means the chosen behavior is documented and covered by regression tests.

Written by the indexing model from the issue text.

Assessment

Tech stack
python
Domain
data
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.