[FieldTrip] Fwd: Modification of ft_timelockgrandaverage cfg.keepindividual

Lucie Charles lucie.charles.ens at googlemail.com
Thu Feb 10 14:03:30 CET 2011


Thank you very much for this very detailed response.

I didn't know (or forgot) that ft_timelockstatistics could take several data
sets as an input (I thought we always needed the big data matrix with all
the subjects). That makes much more sense to remove the option in this
context.

Thanks again,

Lucie

2011/2/10 jan-mathijs schoffelen <jan.schoffelen at donders.ru.nl>

> Dear Lucie,
>
> Thank you very much for your feedback. I take the liberty to anyhow post
> this to the discussion list, so that other people may take notice / join in
> the discussion / etc.
>
> Thanks a lot for this quick response : I understand the logic behind this.
> It's true that I noticed some inconsistencies due to the interpretation of
> the field dimord which can't be well defined if you have both individual and
> average data in your structure.
>
>
> OK
>
> However, I think many people were happy with this option as it was. It's
> quite handy to keep both the average and individual data because you can
> compute statistics and at the same time you don't have to redo the average
> every time. I think a lot of scripts rely on that at least in our lab.
>
>
> The historical purpose for supporting cfg.keepindividual = 'yes', was in
> order to get a representation of all single subjects' data in a single data
> matrix: data.individual. Nowadays, ft_timelockstatistics supports multiple
> data structures in the input, i.e. ft_timelockstatistics(cfg, subj1, subj2
> subj3, etc) so I think the call to ft_timelockgrandaverage could even be
> bypassed.
> The FieldTrip development team is very keen on providing backward
> compatibility support. While in general this is feasible for the functions
> which are in FieldTrip, it is very difficult to realize for lab-specific
> scripts. In this particular example I think that clarity of the data
> representation should prevail over backward compatibility issues,
> particularly because in this case there's an easy workaround: just call
> ft_timelockgrandaverage twice. Moreover, a clean and unambiguous data
> representation is a prerequisite for further developing the software, and
> keeping the historical 'oddity' will only hamper code development.
>
> Furthermore, it's a bit strange to have a function called
> ft_timelockgrandaverage which doesn't compute any grandaverage in some cases
> !
>
>
> I agree, yet see my point above. Some people may just like to have the data
> represented in a single matrix.
>
>
> I would suggest to keep the function as it is but add more options (such as
> cfg.dimord = 'avg' or 'individual') to make the experimenter aware of this
> issue and to solve further computation problem.
>
>
> I hope I could convince you that our philosophy makes sense and that you
> and your lab-mates are willing to make the effort of adjusting the scripts a
> bit for future analyses. If very problematic, I would advice for the current
> analyses to rely on an old version of ft_timelockgrandaverage.
>
> Best wishes,
>
> Jan-Mathijs
>
>
>
> Thank you again,
>
> Lucie
>
> PS : I've sent this email only to you as this is just a suggestion which
> might not be relevant for all users.
>
>
> 2011/2/10 jan-mathijs schoffelen <jan.schoffelen at donders.ru.nl>
>
>> Dear Lucie,
>>
>> Yes, indeed this has recently been changed. The logic behind it is the
>> following:
>>
>> One either typically wants to keep the individuals, OR the average.
>>
>> If in your case you need the average, you have to specify
>> cfg.keepindividual = 'no';
>>
>>  Keeping both the average and the individual leads to an inconsistent
>> definition of the data structure.
>> The field 'dimord' does not allow for an unequivocal interpretation of
>> both indidual and avg are present.
>>
>> If you need both the individual, and the avg, you now need to run
>> ft_timelockgrandaverage twice, once with cfg.keepinididual = 'yes', and once
>> with cfg.keepindividual = 'no';
>>
>> Best wishes,
>>
>> Jan-Mathijs
>>
>>
>> On Feb 10, 2011, at 11:58 AM, Lucie Charles wrote:
>>
>> Hello everyone,
>>
>> It seems that there has been a modification of ft_timelockgrandaverage :
>> now if you specify cfg.keepindividual = 'yes', the grandaverage is computed
>> but is not included in the output of the function (see above).
>>
>> Why is that ? Many of my scripts rely on this option and I wanted to know
>> if there was a good reason for it.
>>
>> Thanks,
>>
>> Lucie
>>
>> New version of ft_timelockgrandaverage (downloaded yesterday), line
>> 159-176
>>
>> %--------------------------------------------
>> % % collect the results
>> %--------------------------------------------
>>
>> grandavg           = [];
>> grandavg.label     = cfg.channel;       % cell-array
>> %grandavg.fsample   = varargin{1}.fsample; % fsample is obsolete
>> grandavg.time      = ResultsTime;       % 1 x Nsamples
>>
>> %KEEP INDIVIDUAL MEANS?
>> if strcmp(cfg.keepindividual, 'yes')
>> *  grandavg.individual = avgmat;         % Nsubj x Nchan x Nsamples
>>   grandavg.dimord = 'subj_chan_time';*
>> else
>> *  grandavg.avg    = ResultGrandavg;     % Nchan x Nsamples*
>>   grandavg.var    = ResultVar;          % Nchan x Nsamples
>>   grandavg.dimord = 'chan_time';
>> end
>>
>> Older version of ft_timelockgrandaverage (april 2010)
>>
>> %--------------------------------------------
>> % % collect the results
>> %--------------------------------------------
>>
>> %SWITCH CHANNEL TO LABEL?
>> grandavg.label     = cfg.channel;       % cell-array
>> grandavg.fsample   = varargin{1}.fsample;
>> grandavg.avg       = ResultGrandavg;        % Nchan x Nsamples
>> grandavg.var       = ResultVar;           % Nchan x Nsamples
>> grandavg.time      = ResultsTime;       % 1 x Nsamples
>>
>> %KEEP INDIVIDUAL MEANS?
>> if strcmp(cfg.keepindividual, 'yes')
>>   grandavg.individual = avgmat;         % Nsubj x Nchan x Nsamples
>>   grandavg.dimord = 'subj_chan_time';
>> else
>>   grandavg.dimord = 'chan_time';
>> end
>>
>>
>> --
>> Lucie CHARLES
>>
>> INSERM-CEA Cognitive Neuroimaging unit
>>
>> CEA/SAC/DSV/DRM/NeuroSpin
>> Bât 145, Point Courrier 156
>> F-91191 Gif/Yvette, FRANCE
>> Tel : +33 1 69 08 99 74
>> Fax : +33 1 69 08 79 73
>>  _______________________________________________
>> fieldtrip mailing list
>> fieldtrip at donders.ru.nl
>> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip
>>
>>
>>  Dr. J.M. (Jan-Mathijs) Schoffelen
>> Donders Institute for Brain, Cognition and Behaviour,
>> Centre for Cognitive Neuroimaging,
>> Radboud University Nijmegen, The Netherlands
>> J.Schoffelen at donders.ru.nl
>> Telephone: 0031-24-3614793
>>
>>
>> _______________________________________________
>> fieldtrip mailing list
>> fieldtrip at donders.ru.nl
>> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip
>>
>
>
>
> --
> Lucie CHARLES
>
> INSERM-CEA Cognitive Neuroimaging unit
>
> CEA/SAC/DSV/DRM/NeuroSpin
> Bât 145, Point Courrier 156
> F-91191 Gif/Yvette, FRANCE
> Tel : +33 1 69 08 99 74
> Fax : +33 1 69 08 79 73
>
>
>  Dr. J.M. (Jan-Mathijs) Schoffelen
> Donders Institute for Brain, Cognition and Behaviour,
> Centre for Cognitive Neuroimaging,
> Radboud University Nijmegen, The Netherlands
> J.Schoffelen at donders.ru.nl
> Telephone: 0031-24-3614793
>
>
> _______________________________________________
> fieldtrip mailing list
> fieldtrip at donders.ru.nl
> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip
>



-- 
Lucie CHARLES

INSERM-CEA Cognitive Neuroimaging unit

CEA/SAC/DSV/DRM/NeuroSpin
Bât 145, Point Courrier 156
F-91191 Gif/Yvette, FRANCE
Tel : +33 1 69 08 99 74
Fax : +33 1 69 08 79 73
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.science.ru.nl/pipermail/fieldtrip/attachments/20110210/cd847c20/attachment.html>


More information about the fieldtrip mailing list