Back to the main page.

Bug 1013 - hassampleinfo fails on a timelocked structure with trials

Status CLOSED WORKSFORME
Reported 2011-10-06 13:04:00 +0200
Modified 2017-12-04 10:08:31 +0100
Product: FieldTrip
Component: core
Version: unspecified
Hardware: PC
Operating System: Mac OS
Importance: P1 normal
Assigned to: Johanna
URL:
Tags:
Depends on:
Blocks:
See also: http://bugzilla.fieldtriptoolbox.org/show_bug.cgi?id=3379

Robert Oostenveld - 2011-10-06 13:04:42 +0200

a.time = [1 2]; a.label = {'chan'}; a.dimord = 'chan_time'; a.avg = [1 1]; a.trial = reshape([3 3; 0 0; 0 0], [3 1 2]); ft_checkdata(a, 'datatype', 'timelock', 'hassampleinfo', 'ifmakessense') ??? Cell contents reference from a non-cell array object. Error in ==> fixsampleinfo at 25 data.fsample = median(1./diff(data.time{1})); Error in ==> ft_checkdata at 585 data = fixsampleinfo(data); Inside fixsampleinfo it presumes that the structure is a raw data structure instead of a timelocked structure


Eelke Spaak - 2011-11-09 10:56:36 +0100

>> a.time = [1 2]; a.label = {'chan'}; a.dimord = 'chan_time'; a.avg = [1 1]; a.trial = reshape([3 3; 0 0; 0 0], [3 1 2]); ft_checkdata(a, 'datatype', 'timelock', 'hassampleinfo', 'ifmakessense') Warning: the data does not contain a trial definition > In utilities/private/warning_once at 81 In utilities/private/fixsampleinfo at 66 In ft_checkdata at 592 Warning: reconstructing sampleinfo by assuming that the trials are consecutive segments of a continuous recording > In utilities/private/warning_once at 81 In utilities/private/fixsampleinfo at 79 In ft_checkdata at 592 ans = time: [1 2] label: {'chan'} dimord: 'chan_time' avg: [1 1] trial: [3x1x2 double] cfg: [] fsample: 1 sampleinfo: [3x2 double]


Robert Oostenveld - 2011-11-11 11:19:36 +0100

I closed all bugs that were recently resolved.


Johanna - 2013-06-07 09:39:46 +0200

I recently worked on (fixed) bugs 2186 and 1495, related to ft_appendtimelock. My fixes there caused test_bug1014 to crash (which is related to this bug as well). I know we've discussed the dimord issue of timelock structures, and still on my to-do list, but the example at the beginning of this bug does not make sense to me. Why would the structure 'a' include .trial field but also have dimord='chan_time'? The output that comes from ft_timelockanalysis either has an .avg field with 'chan_time', or it has both .trial and .avg, but with 'rpt_chan_time' dimord. Whether this is ideal or not, is another question, but just to be consistent with ft_timelockanalysis as it stands now, isn't 'a' incorrect? (The issue of this bug to do with sampleinfo is fixed, and not of concern in my comment here).


Eelke Spaak - 2013-06-07 09:43:35 +0200

(In reply to comment #3) I agree, as per ft_datatype_raw, raw data structures should not have a dimord field. Or if they do, it should be ignored/removed at some point.


Eelke Spaak - 2013-06-18 09:22:37 +0200

(In reply to comment #4) This comment is nonsense, apologies. The data type is not raw at all, I did not read correctly. Let's briefly (!) discuss the correct dimord for timelock structures with keeptrials in the meeting tomorrow.


Johanna - 2013-06-18 09:38:32 +0200

Hi Eelke, no worries about the raw-datatype comment :-) I had a brief chat with Robert after FT meeting last week. He said we should renew this discussion and discuss with the whole team. He said there should be .dimord for the primary field of importance, but that also .avgdimord should be allowed if .avg is secondary to .trial. Likewise, I did not treat the appending correctly when .avg appended to create a .trial. That still needs fixing. (However, note that both Robert and JM won't be in the meeting tomorrow, thus maybe postpone discussion until the following week?)


Robert Oostenveld - 2014-04-14 14:09:15 +0200

I tested it with a = []; a.time = [1 2]; a.label = {'chan'}; a.dimord = 'chan_time'; a.avg = [1 1]; a.trial = reshape([3 3; 0 0; 0 0], [3 1 2]); ft_checkdata(a, 'datatype', 'timelock', 'hassampleinfo', 'ifmakessense') ans = time: [1 2] label: {'chan'} dimord: 'chan_time' avg: [1 1] trial: [3x1x2 double] It all seems fine to me, so I will mark this bug as resolved.