Back to the main page.
Bug 2063 - Problem with freqcomparison reported on email list
| Status | CLOSED FIXED |
| Reported | 2013-03-17 21:43:00 +0100 |
| Modified | 2019-08-10 12:03:43 +0200 |
| Product: | FieldTrip |
| Component: | core |
| Version: | unspecified |
| Hardware: | Other |
| Operating System: | Mac OS |
| Importance: | P3 normal |
| Assigned to: | Arjen Stolk |
| URL: | |
| Tags: | |
| Depends on: | |
| Blocks: | |
| See also: |
Robert Oostenveld - 2013-03-17 21:43:06 +0100
Hi All, I just spotted something that could be a bug in ft_freqcomparison.m (fieldtrip-20130312 and previous versions). Don't now if this is the place for report, but if this really is an issue everyone using this function may be interested. The problem is in line 87 where freq = varargin{1}; is initialized to the *first* freq argument, that according to the doc is used as the norm. So the output (powspctrm) has the dimension of the norm, not the second freq argument, that one wants to become normalized. Strange, hmm? Then, in the following for-loops the index variable runs over the size of the *second* freq argument, updating trials in the powspctrm with the size of the *first* freq argument, which seems simply wrong. Maybe this is an ingenious programming trick, but initializing freq = varargin{2}; on line 87 would make more sense from my point of view. Best, ALEX.
Robert Oostenveld - 2013-03-17 21:44:26 +0100
It should be checked whether this function is nit superceeded by ft_math.
Arjen Stolk - 2013-04-10 11:37:16 +0200
reply on discussion list: Hi Alex, Thanks for looking into this function. You’re right that ft_freqcomparison initializes the output structure ‘ freq’ (line 87) using the first input structure. This could indeed be problematic when the two input structures are dissimilarly sized. In fact, having a size difference in the powspctrm fields between the two input structure is an exclusion criterion for using this function in the first place, e.g. because it may result in comparing frequency powers of different channels, trials, or subjects. For that reason, a check was built in at lines 92 and 115, which ensures that the input structures have identical matrix size. Although not intuitive clear maybe from a reader’s perspective, this is thus not an issue and it will not affect your data. Also please note that ft_freqcomparison has become outdated with the arrival of ft_math. Technically, this function can do the same, but with more flexibility and better bookkeeping. Best wishes, Arjen