Back to the main page.

Bug 2500 - why is cfg.latency in ft_timelockanalysis deprecated?

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
Depends on:
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, 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 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 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).

Jan-Mathijs Schoffelen - 2014-04-02 14:29:38 +0200

bash-4.1$ svn commit -m "enhancement - changed some options from deprecated to forbidden, bug 2500" ft_timelockanalysis.m Sending ft_timelockanalysis.m Transmitting file data . Committed revision 9335.