Back to the main page.
Bug 1683 - order of given parameters affect output of ft_freqgrandaverage
| Status | CLOSED FIXED |
| Reported | 2012-08-31 14:22:00 +0200 |
| Modified | 2019-08-10 11:56:26 +0200 |
| Product: | FieldTrip |
| Component: | core |
| Version: | unspecified |
| Hardware: | PC |
| Operating System: | Windows |
| Importance: | P3 major |
| Assigned to: | Arjen Stolk |
| URL: | |
| Tags: | |
| Depends on: | |
| Blocks: | |
| See also: |
Cornelius Abel - 2012-08-31 14:22:53 +0200
I found a nasty bug in ft_freqgrandaverage which gave me different results depending on the order of cfg.parameters i gave. If i ran ft_freqgrandaverage with cfg.parameters={'powspctr','itc'} or cfg.parameters={'itc','powspctr'} the resulting .itc or .powspctr had different values. The problem occurs because some of my input data had a different numbers of channels than others. So far this shoulnd be a problem, but if you take a look at ft_freqgrandaverage (line 141) you see that the labels of the current input dataset are overwritten in the first iteration with the unique channel selection of all input datasets. The corresponding rows in data matrix are however not removed. That causes a wrong channelselection for the second parameters to be processed because in line 140 channel IDs are picked from the already truncated label list which does not match rows in the data matrix any more. Or am i wrong? Hope i could explain the bug suffiently, Greetings, Cornelius
Jan-Mathijs Schoffelen - 2012-09-02 10:00:38 +0200
Hi Cornelius, Thanks for reporting this. I think that you are quite clear in your description. We will try and fix it as soon as possible. Best, Jan-Mathijs
Jan-Mathijs Schoffelen - 2012-09-02 10:01:33 +0200
Hi Arjen, Could you have a go at this? It seems quite straightforward. If you'd like me to review your changes, let me know.
Arjen Stolk - 2012-09-19 22:45:04 +0200
Thank you, Cornelius. Well-spotted. I have made the channel/time selections (that are common in all subjects) a separate operation per parameter. Since the same bug was also present in ft_timelockgrandaverage, I have made the same change there. Our test-scripts provide no objections. Could you please let me know if this bug is now fixed for you too? I will upload the functions right now. Thanks, Arjen
Arjen Stolk - 2012-09-20 21:27:39 +0200
Consider fixed