noisy.py module should be removed

[sappelhoff]

Before the contributions of @AamnaLawrence @adam2392 and @Nick3151 in #6 there was only the single module noisy.py implementing the "find_noisy_channels" functionality.

Now the full PREP is implemented, including a new "find_noisy_channels" functionality, see: https://github.com/sappelhoff/pyprep/blob/master/pyprep/find_noisy_channels.py

noisy.py should be removed and the find_noisy_channels.py module should be overhauled so that it can be used standalone, without having to run the full PREP.

[Nick3151]

Yeah, I agree. But noisy.py does has some functionality that find_noisy_channels.py does not include. find_bad_epochs. So I think maybe we could:

1. Put find_bad_epochs into a separate file
2. Remove noisy.py
3. Add a notebook on using find_noisy_channels.py standalone

[sappelhoff]

I think that find_bad_epochs is out of the scope for pyprep. IMHO, pyprep should do one thing and do it well --> being a python implementation of the matlab PREP pipeline.

WDYT @yjmantilla

[yjmantilla]

@sappelhoff I think in that case we should make available that functionality in another repo, for example pyfaster or something. I think actually eegfaster exist so maybe that would collide. In any case at least leave it at a gist which we could mention in the pyprep readme if anyone is looking for that.

[yjmantilla]

Another way would be to create a repo specifically for finding noisy stuff including find_noisy_channels and the noisy epochs functions. And then make prep use that module. That way pyprep is the prep implementation and only cares about that and pynoisy (or how that would be called) would only care about finding noisy eeg, being it continuous or epoched.

[sappelhoff]

I think actually eegfaster exist so maybe that would collide

ah, interesting: https://github.com/mdelpozobanos/eegfaster ... but it's not based on MNE (which is not necessarily a drawback)

In any case at least leave it at a gist which we could mention in the pyprep readme if anyone is looking for that.

I took the FASTER code from this gist: https://gist.github.com/wmvanvliet/d883c3fe1402c7ced6fc

I think I'd prefer to mention to remove all non-prep code from this repo and mention the FASTER gist somewhere in the README.

We have to work on more code than we can handle anyways, so removing unneeded things is a good start.

[yjmantilla]

Right now the biggest issues are:

• the mne multitaper filter, which I know there was a windowed version done which we could test.
• the test and validation of the pipeline, which I think are even more important than the filter unless we think of the filter as something absolutely essential of prep.

There was a suggestion too for the API change. So after we eliminate the noisy.py what should our focus be, on your opinion?

[sappelhoff]

Yes, if we could fix the mne multitaper that'd be great ... both for MNE and pyprep. I think it'd be nice to have a working Python implementation for that.

And yes, we need more tests (and better tests) ... and once we have them, we should start refactoring the code without breaking the tests.

re: what to focus on:

1. removing noisy.py is a simple PR < 1hour
2. adding tests can be done incrementally ... whenever somebody has time to take a look and has a good idea
3. biggest chunk is fixing mne multitaper --> that'll have to be done in MNE-Python

---

Other things to do is compare RANSAC in pyprep with RANSAC in autoreject ... and perhaps "unify" them ... take the best of each combination and make one version out of them (probably "enhance" autoreject ransac ... and then make autoreject a dependency in pyprep to import RANSAC from there.)

--> this is also a big job.

So I see two big jobs and some smaller jobs.

Once all of this is done, we can start refactoring :-)

[a-hurst]

@sappelhoff just to your last comment, something else that would be handy for end users (like me) would be a paragraph or two somewhere in the README or docs comparing autoreject to PyPREP and discussing how they relate. For example, is it valid for someone to clean their raw EEG using PyPREP and then try and remove any remaining bad epochs with autoreject, or should they only be used independently?

[sappelhoff]

For example, is it valid for someone to clean their raw EEG using PyPREP and then try and remove any remaining bad epochs with autoreject, or should they only be used independently?

PREP (and pyprep) will interpolate channels .. and autoreject will also interpolate on an epoch level (or drop really bad epochs without trying to interpolate) --> so I guess the danger could be to interpolate a channel based on data that's been already interpolated. And that's like using a copy machine to copy a copy instead of copying the original --> it's getting worse each iteration.

Personally, I would not use prep and autoreject together ... except maybe with heavy testing - but I haven't given it much thought.

Regarding a paragraph to guide users: Sure that'd be helpful, but we'd have to find somebody who wants to pour a lot of testing and knowledge into it :-) I personally don't know much more than what I said in the beginning of this post.