<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Dear Harsimrat,<br>
<br>
Actually, both cumtapcnt and powspctrm should be subselected. The
problem most likely comes from the fact that your data has 32
labels but in powspctrm only one channel left (dimord is
rpt_chan_freq_time, dimension of powspctrm is 73 x 1 x 2 x 3, but
you have 32 labels). Whatever you did to your data, you made it
inconsistent. A way to solve this is to make the label fields have
the sime size as powspctrm. A better way would be to find out what
made them inconsistent. Not sure about freq and time here, because
you mention that these dimension are alright for your tf matrix.<br>
That should solve it. ft_selectdata works with all our test data.
If not, let us know or send me a snippet of your data together
with some code to reproduce this error and I can have a more
thorough look.<br>
<br>
Best,<br>
Jörn<br>
<br>
<br>
On 3/25/2013 6:35 PM, Harsimrat Singh wrote:<br>
</div>
<blockquote
cite="mid:CAN_NhmnOdJ9KJmw=XVf=pvD1HYqdBRs9go7OdW0pObtweXocxw@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_quote">
<div dir="ltr">
<div>
<div>
<div>
<div>Hi All<br>
<br>
I think I have a problem with ft_selectdata. <br>
<br>
Data Background: 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>
Problem: <br>
My total relevant trials are just 13 (class 1) +
20(class2) = 33 for both classes and not 146.<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 after doing ft_selectdata, 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<span class="HOEnZb"><font
color="#888888"><br>
</font></span></div>
<span class="HOEnZb"><font color="#888888">
<div>Harsimrat<br>
</div>
<br>
</font></span></div>
</div>
</div>
</div>
</div>
<div class="HOEnZb">
<div class="h5">
<div class="gmail_extra">
<div class="gmail_quote">On 21 March 2013 08:34, Eelke
Spaak <span dir="ltr"><<a moz-do-not-send="true"
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>
<div><br>
On 20 March 2013 20:55, Ingrid Nieuwenhuis <<a
moz-do-not-send="true"
href="mailto:inieuwenhuis@berkeley.edu"
target="_blank">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 moz-do-not-send="true"
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 moz-do-not-send="true"
href="mailto:fieldtrip@donders.ru.nl"
target="_blank">fieldtrip@donders.ru.nl</a><br>
>> <a moz-do-not-send="true"
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 moz-do-not-send="true"
href="mailto:fieldtrip@donders.ru.nl"
target="_blank">fieldtrip@donders.ru.nl</a><br>
> <a moz-do-not-send="true"
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 moz-do-not-send="true"
href="mailto:fieldtrip@donders.ru.nl"
target="_blank">fieldtrip@donders.ru.nl</a><br>
<a moz-do-not-send="true"
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>
</div>
</div>
</div>
<br>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
fieldtrip mailing list
<a class="moz-txt-link-abbreviated" href="mailto:fieldtrip@donders.ru.nl">fieldtrip@donders.ru.nl</a>
<a class="moz-txt-link-freetext" href="http://mailman.science.ru.nl/mailman/listinfo/fieldtrip">http://mailman.science.ru.nl/mailman/listinfo/fieldtrip</a></pre>
</blockquote>
<br>
<br>
<pre class="moz-signature" cols="72">--
Jörn M. Horschig
PhD Student
Donders Institute for Brain, Cognition and Behaviour
Centre for Cognitive Neuroimaging
Radboud University Nijmegen
Neuronal Oscillations Group
FieldTrip Development Team
P.O. Box 9101
NL-6500 HB Nijmegen
The Netherlands
Contact:
E-Mail: <a class="moz-txt-link-abbreviated" href="mailto:jm.horschig@donders.ru.nl">jm.horschig@donders.ru.nl</a>
Tel: +31-(0)24-36-68493
Web: <a class="moz-txt-link-freetext" href="http://www.ru.nl/donders">http://www.ru.nl/donders</a>
Visiting address:
Trigon, room 2.30
Kapittelweg 29
NL-6525 EN Nijmegen
The Netherlands</pre>
</body>
</html>