Back to the main page.
Bug 1014 - appendtimelock fails if the input contains avg and trial
| Status | CLOSED WORKSFORME |
| Reported | 2011-10-06 13:10:00 +0200 |
| Modified | 2014-05-14 20:08:53 +0200 |
| Product: | FieldTrip |
| Component: | core |
| Version: | unspecified |
| Hardware: | PC |
| Operating System: | Mac OS |
| Importance: | P1 normal |
| Assigned to: | Robert Oostenveld |
| URL: | |
| Tags: | |
| Depends on: | |
| Blocks: | 1021 |
| See also: |
Robert Oostenveld - 2011-10-06 13:10:36 +0200
See the test_bug1014 script, which currently returns c = time: [1 2] label: {'chan'} dimord: 'rpt_chan_time' avg: [2x1x2 double] trial: [4-D double] sampleinfo: [3x2 double] cfg: [1x1 struct] ??? Error using ==> test_bug1014 at 32 the average has incorrect dimensions
Robert Oostenveld - 2011-10-06 13:11:27 +0200
note that c.trial is 4-D, which is also incorrect.
Robert Oostenveld - 2011-10-06 13:16:00 +0200
note that the first part of time: [1 2] label: {'chan'} dimord: 'rpt_chan_time' avg: [2x1x2 double] can be considered correct behaviour, given that dimord=chan_time. If this is indeed the desired behaviour, then the problem is only that it leaves trial in the output and that trial is 4D. I had expected here that avg would be ignored, but given the discussion yesterday, one might say that avg is the primary field (because dimord says so).
Robert Oostenveld - 2011-10-06 13:17:26 +0200
If I change the dimord in the test script to rpt_chan_time, I get the following c = time: [1 2] label: {'chan'} dimord: 'rpt_chan_time' avg: [2x2 double] trial: [6x1x2 double] sampleinfo: [3x2 double] cfg: [1x1 struct] which is also incorrect.
Boris Reuderink - 2011-11-17 10:46:48 +0100
Changed the status of bugs without a specific owner to UNCONFIRMED. I'll try to replicate these bugs (potentially involving the submitter), and change confirmed bugs to NEW. Boris
Jan-Mathijs Schoffelen - 2012-01-27 08:36:46 +0100
assigned bug to get all bugs lined up before the grand bug binge
Johanna - 2012-08-22 16:39:59 +0200
I think Robert already fixed this on Nov 3, 2011. SVN r4667. test_bug1014 runs without errors.
Lilla Magyari - 2013-06-12 14:36:32 +0200
question: what is to happen with a.time = [1 2]; a.label = {'chan'}; a.avg = [1 1]; a.dimord = 'chan_time'; a.trial = reshape([3 3; 0 0; 0 0], [3 1 2]); a.trialdimord = 'rpt_chan_time'; aa = ft_appendtimelock([], a, a) here I would expect aa.trial to contain 2 trials (i.e. the two averages) or perhaps(?) aa.avg = 2x1x2 aa.var = 2x1x2 aa.dimord = 'rpt_chan_time' b.time = [1 2]; b.label = {'chan'}; b.avg = [1 1]; b.avgdimord = 'chan_time'; b.trial = reshape([3 3; 0 0; 0 0], [3 1 2]); b.dimord = 'rpt_chan_time'; bb = ft_appendtimelock([], b, b) here I would expect bb to contain 2*3=6 trials
Johanna - 2013-06-12 14:44:36 +0200
(In reply to comment #7) fyi, comment 7 was written by Robert in discussion with Johanna.
Eelke Spaak - 2013-06-26 13:37:21 +0200
(In reply to comment #7) Discussed at FT meeting today: why do we have .trial anyway? ft_freqanalysis with keeptrials='yes' just gives you an extra 'rpt' dimension in your powspctrm fields. By analogy, ft_timelockanalysis should give avg with a 'rpt' dimension; or better, rename avg to something like 'dat' or 'field'. To be discussed further, perhaps.
Robert Oostenveld - 2013-06-27 18:07:29 +0200
(In reply to comment #9) it is indeed inconsistent to call it avg (the operation applied to the data) versus trial (the observation of the data over multiple repetitions). But then, "dat" is too generic. consistent with freq.powspctrm would be timelock.erp/erf, but that is confusing for the MEG/EEG folks, respectively. event-related-signal is a representational name: timelock.ers? Just as bad as event-related-data (erd). event-related-amplitude? But does it actually matter? If I have ftstructure.xxx with either ftstructure.xxxdimord or ftstructure.dimord it should be fine, right? and ftstructure.xxx ftstructure.xxxdimord ftstructure.yyy ftstructure.yyydimord would be fine. Also ftstructure.xxx ftstructure.dimord <- pertaining to the most important field ftstructure.yyy ftstructure.yyydimord should be fine. I suggest that this one [[X see below X]] is considered valid: timelock.avg timelock.var timelock.dimord = chan_time timelock.cov timelock.covdimord = chan_chan (usually) timelock.trial timelock.trialdimord = rpt_chan_time I leave it up to discussion as to whether cfg.keeptrials=yes should also output timelock.avg (which it does currently) or not (more consistent with other uses of keeptrials). E.g. consider if keeptrials=yes and covariance=yes then timelock.trial timelock.dimord = rpt_chan_time (the most important field) timelock.cov timelock.covdimord = rpt_chan_chan whereas if keeptrials=no and covariance=yes then timelock.avg timelock.var timelock.dimord = chan_time timelock.cov timelock.covdimord = chan_chan (in this case) Perhaps we should just discontinue to output both avg and trial, although according to the data definition [[X see above X]] it should be valid.
Robert Oostenveld - 2013-07-01 20:01:29 +0200
test_bug1014 was failing, although there was not a good reason for it. The output avg was recomputed and therefore consistent with the remainder of the structure. roboos@mentat001> svn commit -m "enhancement - improve check on presence of avg and trial, both are fine as long as consistent with each other" Sending ft_appendtimelock.m Sending test/test_bug1014.m Transmitting file data .. Committed revision 8298.
Robert Oostenveld - 2014-04-14 14:11:01 +0200
the test script test_bug1014 is running though without errors. Furthermore, I have not noticed any unusual behaviour, hence I will mark this bug as resolved. Please reopen (and explain why) if you disagree.