Back to the main page.

Bug 976 - round-off issues lead to unexpected behavior of ft_specest_XXX

Reported 2011-09-22 10:37:00 +0200
Modified 2012-01-03 11:29:08 +0100
Product: FieldTrip
Component: core
Version: unspecified
Hardware: PC
Operating System: Mac OS
Importance: P1 normal
Assigned to: Jan-Mathijs Schoffelen
Depends on:
See also:

Jan-Mathijs Schoffelen - 2011-09-22 10:37:12 +0200

ft_specest_XXX computes the sampling frequency from the first 2 elements of the time axis. This is done for each trial. Sometimes the time samples for some reason are not exactly numerically identical, leading to differences in the number of tapers, even if the trials have the same number of samples. This is nicely illustrated by fieldtrip/test/test_bug905 (see also bug 905). I think that we should try to fix this unexpected behavior. One suggestion (courtesy of Roemer) would be to compute the sampling rate up to some decimal points accuracy (e.g. fsample = round(10000*fsample)/10000

Roemer van der Meij - 2011-09-22 12:25:53 +0200

We could, of course, make sure specest has a sampling rate as input, instead of computing it.

Jan-Mathijs Schoffelen - 2011-12-12 11:04:48 +0100

Craig reported the following: Hi guys, I just wanted to warn you that I'm going to upload an update for ft_specest_mtmfft, which requires an update of ft_freqanalysis. In ft_specest_mtmfft, the sampling rate is determined by time(2) - time(1). This ends up causing numerical accuracy issues when mtmfft is run on a section of data that has been generated from ft_redefine trial. I haven't looked deeply into this, but I suspect that ft_redefine trial is creating the new time vector by subtraction of a scalar value from the original time vector. The numerical error generated is sufficiently large to cause noticeable differences in the spectral output. I have fixed this by passing the fsample into ft_specest_mtmfft. This highlights the overall problem of numerical accuracy and the time vector. We somehow need the time vector always quantized to1/sampling rate. If we represented it as an integer that is divided by the sampling rate, i.e. the time vector is always an integer, the result of subtractions would also always be an integer, then if the time in seconds is wanted, we would divide by the sampling rate, but this would just be a sample index, right? Do the current changes sound ok? Best, Craig

Jan-Mathijs Schoffelen - 2011-12-13 08:43:01 +0100

duplicate of 1228 *** This bug has been marked as a duplicate of bug 1228 ***