Back to the main page.

Bug 2816 - getdimord -- getdimsiz infinite loop

Reported 2015-01-28 23:34:00 +0100
Modified 2015-02-11 10:40:53 +0100
Product: FieldTrip
Component: core
Version: unspecified
Hardware: Macintosh
Operating System: Mac OS
Importance: P5 major
Assigned to: Robert Oostenveld
Depends on:
See also:

Ian Andolina - 2015-01-28 23:34:51 +0100

Hi, I noticed some changes to ft_timelockanalysis (I use the github repo) so wanted to test them out on my data sets. I find code which worked is now breaking, specifically I get into an infinite loop as getdimord calls getdimsiz call getdimord etc: In getdimord (line 140) datsiz = getdimsiz(data, field); In getdimsiz (line 23) dimord = getdimord(data, field); In getdimord (line 64) tmp = getdimsiz(data, 'time'); In getdimsiz (line 23) dimord = getdimord(data, field); In getdimord (line 64) tmp = getdimsiz(data, 'time'); In getdimsiz (line 23) dimord = getdimord(data, field); ... ... ... called from: In ft_selectdata (line 180) dimord{i} = getdimord(varargin{1}, datfield{i}); In ft_timelockanalysis (line 131) data = ft_selectdata(tmpcfg, data); In LFPAnalysis/ftTimeLockAnalysis (line 473) av{i} = ft_timelockanalysis(cfg, ft); my cfg looks like: cfg = covariancewindow: [0.1 0.2] keeptrials: 'yes' removemean: 'yes' covariance: 'yes' channel: 'TETFP10' trials: [1x65 double] and ft data: ft = hdr: [1x1 struct] label: {'TETFP09' 'TETFP10' 'TETFP11' 'TETFP12'} time: {1x142 cell} trial: {1x142 cell} fsample: 1000 sampleinfo: [142x2 double] trialinfo: [142x1 double] cfg: [1x1 struct] I create my data myself, so its possible this is triggered by something specific to my dataset. I can make a minimal dataset if necessary but suspect this is just due to recent the restructuring. Line 23 was edited recently: As an aside I also noticed a small typo:

Robert Oostenveld - 2015-01-29 08:24:02 +0100

Hi Ian, Sorry, this must have been my bad. I recall some issue with the infinite recursion during the development, but thought I had resolved it. Apparently not. Thanks for the quick notification, I will be on it immediately. Robert

Robert Oostenveld - 2015-01-29 08:48:01 +0100

I found it. It was specific to raw data due to the cell-array "time" field. The motivation for the recursion had to do with a section of code in ft_XXXstatistics (each of them) where getdimsiz was supposed to also return the trailing singleton dimension. I solved it locally in those functions and removed the recursion between the two functions. mac011> svn commit Sending ft_freqstatistics.m Sending ft_sourcestatistics.m Sending ft_timelockstatistics.m Adding test/test_bug2816.m Sending utilities/private/getdimsiz.m Transmitting file data ..... Committed revision 10140. I also swapped the alpha and tail options. mac011> svn commit ft_statistics_analytic.m Sending ft_statistics_analytic.m Transmitting file data . Committed revision 10143.

Robert Oostenveld - 2015-02-11 10:40:53 +0100

Closed several bugs that were recently resolved. Please reopen if you are not happy with the resolution.