<div dir="ltr"><div><div><div><div>Hi All<br><br>I think I am missing something with ft_selectdata. I investigated a bit more while redoing the analysis with new version of fieldtrip.<br><br>I have 4 class data but i am just doing classification (multivariate analysis) between
the first two classes with 13 and 20 trials each. <br>After the ft_freqanalysis - all the trials are
contained in tf - and tf.powsctrm is 4D (73*1*3*4) - [trials, channel,
freq, time] - Here, I have one channel as I removed others.<br>When I use <br>tf1 = ft_selectdata(tf, 'rpt', data1.trlvec(1:end)); <br>to get trials for only the first class <br>I get <br> label: {32x1 cell}<br>
dimord: 'rpt_chan_freq_time'<br> freq: [10.5000 12.5000 14.5000]<br> time: [0.3000 0.4000 0.5000 0.6000]<br> powspctrm: [4-D double]<br> cumtapcnt: [13x3 double]<br> cfg: [1x1 struct]<br>
<div>Now, the size of tf1.powspctrm is (73, 1, 2, 3) which is same as tf.powspctrm<br></div><div>Similarly, for trials of class 2<br>tf2 = ft_selectdata(tf, 'rpt', data2.trlvec(1:end)); <br></div><div>Again, the size of tf2 is same as tf1 which is same as tf<br>
</div><div>The only difference in the structure is <br>tf2.cumtapcnt which is 20 for tf2, 13 for tf1 and 73 for tf.<br></div><div><br>The first question is- <br></div><div>How does ft_freqstatistics handle tf1.cumtapcnt, when I use <br>
</div><div>stat = ft_freqstatistics(cfg,tf1,tf2)<br></div><div>Is tf1. cumtapcnt telling the ft_freqstatistics which trials to use of tf1?<br></div><div>This only works if I design the label as <br>cfg. design = [ones(size(tf1.powspctrm,1),1);2*ones(size(tf2.powspctrm,1),1)]'<br>
its size is 73*2 =146<br></div><div><br>But my total relevant trials are just 13 (class 1) + 20(class2) = 33 for both classes<br></div><div>I
suspect I making a mistake somewhere as in ideal case I should be
designing cgf.design = [ones(size(tf1.cumtapcnt,1),1);
2*ones(size(tf2.cumtapcnt,1),1)]'<br></div><div>size(cg.design) should be 33<br></div><div>and tf1.powspctrm should have size [13 1 3 4] and tf2 should have size [20 1 3 4]<br></div><div><br></div><div>So ft_freqstatistics should be handling 33 trials - with 13 from first class, 20 from other class. <br>
</div><div>But now it has full 146 trials even after doing ft_selectdata.<br></div><div>I will be very grateful for any help.<br><br></div><div>Best regards<br></div><div>Harsimrat<br></div> <br></div></div></div></div></div>
<div class="gmail_extra"><br><br><div class="gmail_quote">On 21 March 2013 08:34, Eelke Spaak <span dir="ltr"><<a href="mailto:eelke.spaak@donders.ru.nl" target="_blank">eelke.spaak@donders.ru.nl</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Ingrid,<br>
<br>
Thanks for your question; it made me realize that my e-mail was not<br>
clear enough. In your case, when you repaired channels that were still<br>
present in the data, the output channel order of ft_channelrepair will<br>
be the same as the input channel order.<br>
<br>
The problem only occurs if you use ft_channelrepair to repair<br>
*missing* channels, so e.g. channels switched off during acquisition<br>
or that were discarded during preprocessing.<br>
<br>
Groeten,<br>
Eelke<br>
<div class="HOEnZb"><div class="h5"><br>
On 20 March 2013 20:55, Ingrid Nieuwenhuis <<a href="mailto:inieuwenhuis@berkeley.edu">inieuwenhuis@berkeley.edu</a>> wrote:<br>
> Hi Eelke,<br>
><br>
> Thanks for reporting. I did do ft_channelrepair on my EEG data for some<br>
> subjects and subsequently used ft_freqstatistics. However, the channel order<br>
> is indentical in all my subjects in the freq.<br>
><br>
> I repaired bad channels using the default setting (method='nearest'). The<br>
> bad channels were included in the input data to ft_channelrepair (so they<br>
> were not missing). I just checked, and in data_out after ft_channelrepair,<br>
> the order of the labels of the data is identical to the data_in, thus the<br>
> repaired channels were NOT appended to the end of the data. So apparently<br>
> ft_channelrepair not always appends the repaired channels at the end. I<br>
> suppose this is good news for me, meaning that the bug did not affect me,<br>
> since the channels were ordered identically when calling ft_freqstatistics.<br>
> Do you agree, or am I missing something? And for others that used<br>
> ft_channelrepair, might be worth checking if the ordering is indeed changed<br>
> after calling it, because it appears not always to be the case.<br>
><br>
> Thanks,<br>
> Ingrid<br>
><br>
><br>
> On 3/20/2013 2:01 AM, Eelke Spaak wrote:<br>
>><br>
>> Dear FieldTrip community,<br>
>><br>
>> Short version: if you did ft_freqstatistics across subjects with a<br>
>> different channel ordering across data sets (which is the case if you<br>
>> use ft_channelrepair), your results might have been erroneous. Read<br>
>> the following carefully.<br>
>><br>
>> Yesterday, we discovered a possibly severe bug in a utility function<br>
>> (ft_selectdata_old) which was used by ft_freqstatistics. The bug<br>
>> entails that ft_selectdata_old assumes that the channels in all data<br>
>> input arguments are ordered identically, and does not take into<br>
>> account the order of the data.label field. This means that when<br>
>> several data input arguments with different channel orderings are<br>
>> passed to ft_selectdata_old, the resulting output structure (with a<br>
>> newly added 'rpt' dimension) will contain wrong data (i.e. data for<br>
>> channel X might end up in another channel Y). Importantly, the same<br>
>> thus holds for ft_freqstatistics: when doing statistics across<br>
>> subjects, if the different subjects' data sets have different channel<br>
>> orderings, the resulting statistics will be wrong.<br>
>><br>
>> We expect that in many cases, the channel ordering across different<br>
>> data sets will be identical, and in those cases this bug will not have<br>
>> had any effect. However, one important case in which channel ordering<br>
>> *will* be different is when one does ft_channelrepair on a data set,<br>
>> since this function appends the repaired channels to the end of the<br>
>> data. So, if you have done ft_channelrepair on only a subset of your<br>
>> subjects' data, and/or used ft_channelrepair to repair different<br>
>> channels in different subjects, and subsequently passed the repaired<br>
>> data sets to ft_freqstatistics, there is a good chance the results you<br>
>> got were wrong.<br>
>><br>
>> Most likely, this bug was introduced with revision 4101, in september<br>
>> 2011, so it has been in the code for quite a while. Note that<br>
>> ft_channelrepair only supports repairing missing channels since<br>
>> revision 5216 (february 2012), and that this was advised against until<br>
>> revision 6100 (june 2012), when the algorithm for doing so sensibly<br>
>> was implemented.<br>
>><br>
>> The fix has been implemented and is now available from the FTP server<br>
>> as of fieldtrip-20130319 (Donders users: the fix is automatically<br>
>> available on the /home/common/ version of FieldTrip). Note that<br>
>> ft_selectdata_old still does not work correctly, this is something we<br>
>> will fix in the near future (ft_selectdata_old is deprecated). We<br>
>> fixed the behaviour of ft_appendfreq (the preferred replacement<br>
>> function for ft_selectdata_old when appending freq structures) and<br>
>> changed ft_freqstatistics to use this function instead.<br>
>><br>
>> The other statistics functions, ft_timelockstatistics and<br>
>> ft_sourcestatistics, were not affected by this bug. We strongly advise<br>
>> you to upgrade to the latest version of FieldTrip. If the situation<br>
>> described above applies to you, you will need to redo your<br>
>> channel-level (time-)frequency statistics analyses.<br>
>><br>
>> Details on the bug (and a test script) can be found here:<br>
>> <a href="http://bugzilla.fcdonders.nl/show_bug.cgi?id=2069" target="_blank">http://bugzilla.fcdonders.nl/show_bug.cgi?id=2069</a> If you find any<br>
>> problems related to the bug, please post them there.<br>
>><br>
>> We sincerely apologise for this bug and any trouble it might have caused.<br>
>><br>
>> Best,<br>
>> On behalf of the FT core development team,<br>
>><br>
>> Eelke<br>
>> _______________________________________________<br>
>> fieldtrip mailing list<br>
>> <a href="mailto:fieldtrip@donders.ru.nl">fieldtrip@donders.ru.nl</a><br>
>> <a href="http://mailman.science.ru.nl/mailman/listinfo/fieldtrip" target="_blank">http://mailman.science.ru.nl/mailman/listinfo/fieldtrip</a><br>
><br>
><br>
> --<br>
> Ingrid Nieuwenhuis PhD<br>
> Postdoctoral Fellow<br>
> Sleep and Neuroimaging Laboratory<br>
> Department of Psychology<br>
> University of California, Berkeley<br>
> California 94720-1650<br>
> Tolman Hall, room 5305<br>
><br>
><br>
> _______________________________________________<br>
> fieldtrip mailing list<br>
> <a href="mailto:fieldtrip@donders.ru.nl">fieldtrip@donders.ru.nl</a><br>
> <a href="http://mailman.science.ru.nl/mailman/listinfo/fieldtrip" target="_blank">http://mailman.science.ru.nl/mailman/listinfo/fieldtrip</a><br>
_______________________________________________<br>
fieldtrip mailing list<br>
<a href="mailto:fieldtrip@donders.ru.nl">fieldtrip@donders.ru.nl</a><br>
<a href="http://mailman.science.ru.nl/mailman/listinfo/fieldtrip" target="_blank">http://mailman.science.ru.nl/mailman/listinfo/fieldtrip</a><br>
</div></div></blockquote></div><br></div>