question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Crop-like option for TFR with `fmin` and `fmax`

See original GitHub issue

I’ve found out during classes where I teach mne that .crop-like operations are usually much more intuitive for students than having to dive into the data array and index it. With tfr they usually want to, for example selecte a time range and frequency range and then average (or not) and use in further computations/visualisations. If you agree it would be useful, there are two options:

adding fmin and fmax to TFR.crop()

This would allow for example for

tfr.crop(tmin=0.2, tmax=0.4, fmin=5, fmax=7)

@larsoner mentioned that he does not like this solution very much because .crop() sounds more time-related and it would stay to mean “crop in time” if we instead add another method for freq-cropping (Eric, please correct me if I misrepresent). I actually like putting it all into .crop() since I much prefer using kwargs anyway for clarity. Also crop sounds to me equally well suited for time, space or frequency (like trim, for example, but I’m not a native so my argument is weaker here 😃 ). I also think it would be easier for new mne users (like my students) to digest - one method for selection instead of multiple methods depending on the dimension type.

adding another method for frequency cropping

Another method that would work like .crop() but for frequency dimension. I don’t have a good idea for the method name in this case but just assuming it would be called .frop() the example from previous section would be:

tfr.crop(tmin=0.2, tmax=0.4).frop(fmin=5, fmax=7)

obviously I’m not suggesting to actually call it .frop() 😃

Issue Analytics

  • State:closed
  • Created 5 years ago
  • Comments:13 (13 by maintainers)

github_iconTop GitHub Comments

1reaction
larsonercommented, Jan 29, 2019

Yes we should just override it in the TFR classes.

1reaction
larsonercommented, Jan 29, 2019

Thinking about it more, I’m fine with crop. If we think of a “crop” operation as “trimming the current raw / average / epoch / source data for all channels/sources”, then you can crop in freq just as easily as time, and it’s different from other forms of subselection we have, such as trimming the set of epochs with epochs[10:20], subselecting source vertices with stc.in_label, or the set of channels with epochs.pick_types, etc.

Read more comments on GitHub >

github_iconTop Results From Across the Web

Federal Aviation Administration - Graphic TFR's
Date NOTAM Facility State Type 12/21/2022 2/8274 ZMP MN HAZARDS 12/21/2022 2/8126 ZHN HI HAZARDS 12/20/2022 2/8103 ZKC KS HAZARDS
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found