Back to the main page.
Bug 2500 - why is cfg.latency in ft_timelockanalysis deprecated?
| Status | CLOSED FIXED |
| Reported | 2014-03-14 14:08:00 +0100 |
| Modified | 2014-06-18 12:32:13 +0200 |
| Product: | FieldTrip |
| Component: | core |
| Version: | unspecified |
| Hardware: | PC |
| Operating System: | Windows |
| Importance: | P5 normal |
| Assigned to: | Jan-Mathijs Schoffelen |
| URL: | |
| Tags: | |
| Depends on: | |
| Blocks: | |
| See also: |
Eelke Spaak - 2014-03-14 14:08:13 +0100
(See also bug 744 ("cfg.latency should be made forbidden/deprecated in ft_timelockanalysis", closed) and bug 745 ("similar to cfg.trials and cfg.channel, functions should get an option cfg.latency", still open :) .) I think it would be very helpful. Note, by the way, that right now specifying cfg.latency results in a deprecation warning, however the parameter has no effect, which might be a bit confusing to the user. I would be in favour of re-implementing cfg.latency functionality, rather than making it forbidden. In any case, keeping it deprecated is undesired, as it does not work at the moment.
Eelke Spaak - 2014-03-14 14:10:29 +0100
YAY! Bug 2500 :D
Johanna - 2014-03-14 14:11:30 +0100
See also bug 656 and discussion of cfg.covlatency
Jörn M. Horschig - 2014-03-14 14:22:05 +0100
If I recall correctly, one reason was that data management should be in hands of the user by immediate calls to high-level functions. That means that the user should call ft_selectdata first before calling ft_timelockanalysis. This is bug 1376. As this is obviously not correspondance with bug 745. Do we need to discuss this in the next meeting and settle on these guidelines? I think it would be great if we finally settle on what cfg options should be shared across (similar) functions and what rationale we want to use for that.
Eelke Spaak - 2014-03-14 14:24:39 +0100
(In reply to Jörn M. Horschig from comment #3) Good idea to discuss this. I already guessed that something like this was the rationale. However, I also recall a fairly recent discussion about the cfg.preproc.xxx option for ft_timelockanalysis, and in the end we decided to keep that. To me a cfg.latency 'shorthand' option would make more sense than a preproc shorthand option, so I guess we by the same rationale should then also vote to keep cfg.latency and cfg.channel and cfg.trials.
Johanna - 2014-03-14 14:37:59 +0100
One aspect of bug 656 also was the idea that ft_timelockanalysis could call itself with a series of latencies, so that the covariance over many adjacent/overlapping time windows could created from a longer time window as input data. I did create all this in a version that was never committed, but is sitting in the 'attachments' of bug 656. That used cfg.toi rather than latency to be more in line with ft_freqanalysis.
- 2014-04-02 13:28:43 +0200
Discussed (20140402): By executive vote we voted against cfg.latency to be re-implemented. It should be made forbidden. The functionality, although similar to channel and trials, is more trivial than channel and trials, and it moreover does not affect the output (as opposed to trials).