Back to the main page.

Bug 2786 - merge ft_freqgrandaverage with ft_timelockgrandaverage

Status NEW
Reported 2014-12-17 15:51:00 +0100
Modified 2019-03-28 11:04:53 +0100
Product: FieldTrip
Component: core
Version: unspecified
Hardware: PC
Operating System: Mac OS
Importance: P5 minor
Assigned to:
URL:
Tags:
Depends on:
Blocks:
See also:

Robert Oostenveld - 2014-12-17 15:51:24 +0100

At this moment ft_timelockgrandaverage has most functionality. They should only differ in bookkeeping, and due to bug 2785 the bookkeeping in ft_timelockgrandaverage is now the cleanest. I suggest to solve this just like ER/TFR functions, i.e. have one call the other.


Jan-Mathijs Schoffelen - 2019-03-28 10:55:30 +0100

Both functions are actually quite ugly and not according to current fieldtrip standards (e.g. using ft_selectdata for data 'alignment' across input arguments. Also, ft_sourcegrandaverage exists. Also, ft_appendXXX functions do a lot of the work that the XXXgrandaverage functions also have. 'keepindividual' functionality can be mimicked by: ft_appendXXX with appenddim = 'rpt': difference: individual subjects will be represented in the dimord as 'rpt', and in the field with the same name as the input data. This as opposed to the 'individual' field in XXXgrandaverage without 'keepindividual', a call to ft_appendXXX can be followed by a call to ft_selectdata with avgoverrpt. Key differences will be the handling of 'var' and 'dof' in timelockgrandaverage, and the 'across' versus 'within' computation, where the computation of the variance across input arguments I can not completely follow


Robert Oostenveld - 2019-03-28 11:00:37 +0100

I recall that Burkhard (now CC) implemented the within/between. Loosely/vaguely: the idea is that you can use it either to combine variance across conditions within a subject, i.e. mimic the behavior that you would get, had you done timelockanalysis on all conditions together (except that the mean would be condition specific). And the alternative is to compute pooled variance across subjects. In the 1st case you want to deal with the number of trials in each condition (each trial shoudl weigh equally), in the 2nd you want each subject to be weighted equally, also if some subjects have more or less trials.


Jan-Mathijs Schoffelen - 2019-03-28 11:04:53 +0100

Yes, indeed, I thought that, too. But the 'within' pooling is not fully correct, because it assumes that the means are equal across the conditions to-be-combined, otherwise doing some weighted averaging wizardry on the variance does not make sense at all I'd say. I think that a clean re-implementation of the function would be then to use ft_appendtimelock up until the point that the non-standard stuff is done: at least the bookkeeping operations on the input data arguments will then be outsourced to ft_selectdata.