Back to the main page.
Bug 1734 - redefining indentical trials resulting in different number of samples
| Status | CLOSED WONTFIX |
| Reported | 2012-09-21 15:26:00 +0200 |
| Modified | 2019-08-10 11:55:42 +0200 |
| Product: | FieldTrip |
| Component: | core |
| Version: | unspecified |
| Hardware: | Other |
| Operating System: | Linux |
| Importance: | P3 normal |
| Assigned to: | |
| URL: | |
| Tags: | |
| Depends on: | |
| Blocks: | |
| See also: |
Ayelet N. Landau - 2012-09-21 15:26:43 +0200
When I run redefinetrial as following: winlen = 0.5 cfg = []; cfg.toilim = [-0.50 0]; cfg.minlength = winlen; data1 = ft_redefinetrial(cfg, data); where data has data.Fs = 100 I get an output with mostly 51 samples per trial. Strangely and scarcely there will be an occasional trial that will have a different number of samples (i.e. 50). This generates problems later when I try to append data along the channel dimension. I was able to redeem this problem by asking for a winlen of 0.501
Jan-Mathijs Schoffelen - 2012-09-21 15:31:21 +0200
Hi Ayelet, I am not sure, but ft_redefinetrial either uses toilim or uses minlength. I don't know which one has precedence. Note that for the toilim functionality, the edges are inclusive, i.e. it will generally lead to the requested number of samples + 1. In you case it seems as if there are rounding issues for some of the trials, which yield the expected 50 samples in your case. If the documentation of the function can be made more clear, please feel free to suggest improvements. The more explicit they are spelled out, the more likely they will be incorporated in the help...
Jan-Mathijs Schoffelen - 2012-09-21 15:35:19 +0200
Oops. Forget about my previous statement with respect to minlength and toilim: I confused minlength with the length option. Your issue indeed boils own to the inclusive-edges issue, in combination with slight rounding issues in the individual trials' time axes. I'd consider specifying cfg.toilim to be [-0.5 -0.01], and cfg.minlength 0.499 ;-)
Ayelet N. Landau - 2012-09-21 16:23:12 +0200
I don't have a problem with having 51 samples. That is absolutely fine by me. The reason I report this as a bug is that I would think its a bit problematic that the same data produce different outputs. I realize that there are ways around this. But I wonder whether an additional "tolerance" or "number of samples" parameter could be added so that precision issues won't generate this inconsistency (which will cause trouble later in the analysis pipeline. I hope this is clearer and apologies if the purpose of my bug report previously wasn't. Ayelet
Robert Oostenveld - 2012-09-22 14:08:45 +0200
I agree that it is to be expected that although random rounding-off errors in the sample time can happen, they should be consistent over trials. We have a piece of code somewhere that aligns sample time points, but apparently that does not yet solve it for this specific issue. Can you attach a test file to reproduce the bug, preferably a small one? Perhaps you can take the one you have and just remove all but one channel. I will look up the old bug reports on this issue.
Robert Oostenveld - 2012-09-22 14:10:40 +0200
(In reply to comment #4) related are bug 976 and probably also bug 1228.
Jan-Mathijs Schoffelen - 2012-11-07 13:40:50 +0100
Hi Ayelet, Is this still a problem for you? We did not see a test file, so we assume it to be OK for now. Without some additional info we cannot tackle this one and we will close the bug. Agreed? Feel free to re-open it.
Robert Oostenveld - 2019-08-10 11:51:45 +0200
This closes a whole series of bugs that have been resolved (either FIXED/WONTFIX/INVALID) for quite some time. If you disagree, please file a new issue describing the issue on https://github.com/fieldtrip/fieldtrip/issues.