Back to the main page.
Bug 1488 - ft_specest_mtmfft should support variable number of tapers over frequencies
| Status | CLOSED FIXED |
| Reported | 2012-05-24 17:06:00 +0200 |
| Modified | 2013-01-17 10:42:44 +0100 |
| Product: | FieldTrip |
| Component: | specest |
| Version: | unspecified |
| Hardware: | PC |
| Operating System: | Windows |
| Importance: | P3 enhancement |
| Assigned to: | Roemer van der Meij |
| URL: | |
| Tags: | |
| Depends on: | |
| Blocks: | |
| See also: |
Roemer van der Meij - 2012-05-24 17:06:32 +0200
For when taper = dpss, using tapsmofrq. Similar to ft_specest_mtmconvol. Question to be answered, should it also be supported in ft_freqanalysis or not. Regardless of the answer, it can be implemented in specest_mtmfft.
Roemer van der Meij - 2012-09-12 12:31:53 +0200
Was fixed a week ago, but didn't update the bug at the time cause the bugzilla server was out of the air. Ft_specest_mtmfft now supports variable number of slepian tapers the same way mtmconvol does. That is, there is now an additional input argument 'dimord', which can be 'chan_freqtap' or 'tap_chan_freq' (default). These determine the format of the output spectrum. 'tap_chan_freq' fills spectrum with NaNs when a given frequency has less tapers than max(ntaper). 'chan_freqtap' is much smaller and faster, but requires indexing based on ntaper to get the proper data out.
Roemer van der Meij - 2012-09-12 12:34:16 +0200
Almost forgot, because the number of tapers to be computed is so incredibly large, ft_specest_mtmfft now uses the persistent variable trick to save and reuse the 'taper state' in subsequent function calls. I also added it to ft_specest_mtmconvol, for a tiny speed increase because it was easy to do anyway.