Back to the main page.
Bug 979 - mtmfft: cumtapcnt doesn't support variable number of tapers
| Status | CLOSED WONTFIX |
| Reported | 2011-09-22 13:14:00 +0200 |
| Modified | 2011-10-26 16:22:38 +0200 |
| Product: | FieldTrip |
| Component: | specest |
| Version: | unspecified |
| Hardware: | PC |
| Operating System: | All |
| Importance: | P1 normal |
| Assigned to: | Jan-Mathijs Schoffelen |
| URL: | |
| Tags: | |
| Depends on: | |
| Blocks: | |
| See also: |
Roemer van der Meij - 2011-09-22 13:14:07 +0200
Cumtapcnt now only contains, per trial, a number instead of a vector. Hence, it doesn't support variable number of tapers. This field is used in ft_freqdescriptives if I'm correct, so we cannot just change it into a vector. Which other functions use the cumtapcnt field?
Jan-Mathijs Schoffelen - 2011-09-22 13:29:08 +0200
Hi Roemer, I think you are mixing up things a bit here. Cumtapcnt should be a vector Ntrials x 1. At least this is the behavior all functions that use it expect. The issue you refer to is related to mtmconvol. The bottom line is that for mtmfft all frequencies by construction always have the same number of tapers, for a given trial. Therefore, it suffices to indicate this with 1 value per trial, justifying the dimensions of the cumtapcnt field. In the past we had some discussions related to the variable number of tapers (over frequencies) in the context of mtmconvol. As far as I can remember this has not been resolved yet, and it even seems that the cumtapcnt field is not created correctly (as in: functions that use it get confused when trying to make sense of the cumtapcnt field when the data comes from mtmconvol).
Jan-Mathijs Schoffelen - 2011-09-22 13:35:38 +0200
One addition: this is what cumtapcnt is supposed to do: each entry corresponds to a trial, and indicates how many tapers went into this estimate. in other words: sum(freq.cumtapcnt)==size(freq.fourierspctrm,1) if cfg.keeptrials = 'yes' and cfg.keeptapers = 'no', the cumtapcnt field is still relevant because it indicates the dof for that trial. for TFRs in principle it should be possible to support variable number of tapers per frequency (note that in the case of mtmconvol per construction the number of tapers for a given frequency is fixed over trials (because the t_ftimwin does not change)). This is of course only supported when cfg.keeptrials = 'yes' but cfg.keeptapers = 'no'; Thus with cfg.output='fourier' it should throw an error, because of the fact that we are concatenating along the dimension of the tapers (and thus if some frequency has fewer tapers it does not fit). In the first case it would make sense to indeed make the cumtapcnt field NtrialsxNfreq, but only in the case that this adds information (i.e. the number of tapers over frequencies not being constant)