Back to the main page.
Bug 1693 - ft_freqanalysis should support variable number of tapers over frequencies for method = mtmfft, taper = dpss
| Status | ASSIGNED |
| Reported | 2012-09-03 14:10:00 +0200 |
| Modified | 2013-01-18 10:43:31 +0100 |
| Product: | FieldTrip |
| Component: | core |
| Version: | unspecified |
| Hardware: | PC |
| Operating System: | Windows |
| Importance: | P3 normal |
| Assigned to: | Roemer van der Meij |
| URL: | |
| Tags: | |
| Depends on: | |
| Blocks: | |
| See also: |
Roemer van der Meij - 2012-09-03 14:10:08 +0200
Roemer van der Meij - 2012-09-03 14:10:50 +0200
Before this, it should be supported by ft_specest_mtmfft first: http://bugzilla.fcdonders.nl/show_bug.cgi?id=1488 This is a minor task though, hence the separate bugs.
Eelke Spaak - 2012-09-03 14:14:27 +0200
I've always understood this is a bad idea; rather if you want to use different tapers for different frequencies, just do ft_freqanalysis twice, and then keep in mind that the statistics will not cluster across the boundary, so to speak. But perhaps I was misinformed and/or misunderstand the point?
Roemer van der Meij - 2012-09-03 14:23:58 +0200
Things to look out for: * unwrapping the freqtap dimension (look at mtmconvol for example) * bookkeeping number of tapers * correctly handle NaNs in frequencies with less than max tapers, or maybe they are not necessary (look at mtmconvol) * cumtapsum/cumtapcnt! This field is used in other functions, if a format change is necessary (e.g. scalar vs vector representation), make sure all functions using this field support it equally well @Eelke I kinda forgot the word 'number' in the title :).
Roemer van der Meij - 2012-09-03 14:25:09 +0200
(accidentally posted too early) Title is fixed now, was only referring to number of tapers for dpss, i.e. variable smoothing.
Roemer van der Meij - 2012-09-05 17:08:37 +0200
Functions that might be affected (or at least whose cumtapcnt should be adjusted/checked) (probably an over-estimation) grep -l 'chan_freq_' ./*.m ./*/*.m ./*/*/*.m ./*/*/*/*.m ./*/*/*/*/*.m ./*/*/*/*/*/*.m ./besa2fieldtrip.m ./ft_freqanalysis.m ./ft_freqanalysis_mvar.m ./ft_freqbaseline.m ./ft_freqgrandaverage.m ./ft_freqinterpolate.m ./ft_movieplotTFR.m ./ft_qualitycheck.m ./ft_regressconfound.m ./ft_sourceanalysis.m ./ft_topoplotTFR.m ./forward/ft_apply_montage.m ./private/moviefunction.m ./private/prepare_freq_matrices.m ./private/prepare_timefreq_data.m ./private/statistics_wrapper.m ./statfun/ft_statfun_actvsblT.m ./test/test_bug1168.m ./test/test_bug1357.m ./test/test_bug1556.m ./test/test_bug931.m ./test/test_ft_appendfreq.m ./test/test_ft_conjunctionanalysis.m ./test/test_ft_freqgrandaverage.m ./test/test_ft_freqstatistics.m ./test/test_ft_regressconfound.m ./test/test_ft_selectdata.m ./utilities/ft_checkdata.m ./utilities/ft_datatype_freq.m ./contrib/spike/ft_spiketriggeredspectrum_stat.m
Jan-Mathijs Schoffelen - 2012-09-12 13:30:49 +0200
discussed the issue a bit more. Roemer is checking how slightly varying half-bandwidth parameters are going to change the shape of the tapers (even if the total number of tapers does not change). Important to compute the tapers per frequency, which is computationally not efficient....
Jan-Mathijs Schoffelen - 2012-09-12 13:31:04 +0200
discussed the issue a bit more. Roemer is checking how slightly varying half-bandwidth parameters are going to change the shape of the tapers (even if the total number of tapers does not change). Important to compute the tapers per frequency, which is computationally not efficient....