<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>