Back to the main page.
Bug 976 - round-off issues lead to unexpected behavior of ft_specest_XXX
| Status | CLOSED DUPLICATE |
| 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 |
| URL: | |
| Tags: | |
| Depends on: | |
| Blocks: | |
| 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