mne-tools / mne-tools/mne-python
Drop log handling in sliced epochs not intuitive
Nobody has claimed this yet.
- 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
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- 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