Back to the main page.
Bug 1939 - should ft_selectdata_new modify the output.cfg?
| Status | CLOSED FIXED |
| Reported | 2013-01-18 14:17:00 +0100 |
| Modified | 2014-03-12 12:21:35 +0100 |
| Product: | FieldTrip |
| Component: | core |
| Version: | unspecified |
| Hardware: | PC |
| Operating System: | Windows |
| Importance: | P3 normal |
| Assigned to: | Jörn M. Horschig |
| URL: | |
| Tags: | |
| Depends on: | |
| Blocks: | |
| See also: |
Johanna - 2013-01-18 14:17:34 +0100
If I do something like: cfg=[]; cfg.avgoverfreq='yes'; freqfa=ft_selectdata_new(cfg,freq); then isequal(freq.cfg,freqfa.cfg) is true. I would prefer to see the cfg of freqfa reflect the fact that ft_selectdata_new was called and with what cfg options. Ideally this could also be for ft_selectdata_old but I guess not possible with the key-value pair way of doing the options.
Robert Oostenveld - 2013-01-18 16:12:39 +0100
the output cfg should reflect what was used. So cfg.toilim = [-inf inf] should be replaced by finite numbers that match the time axis. Last week in the FT meeting we decided that in the future we will add the user specified input-cfg to the provenance info as well, next to the used-cfg. That first requires that the used-cfg is trimmed down a bit, otherwise it gets too heavy. And we have to consider how to deal with ft functions that call other ft functions (like ft_freqstats calling ft_selectdata or ft_volumerealign calling ft_volumedownsample). So or the moment we should stick to the used-cfgs in the outputs.
Johanna - 2013-01-18 16:18:13 +0100
Ok. To clarify, I'm not disagreeing with what was decided in last week's meeting. I just am questioning if in the example I gave, should freqfa.cfg should reflect the used-cfg from ft_freqanalysis (how freq was created) or the used-cfg from ft_selectdata_new? So I guess this falls under your question of how to deal with ft_functions calling other ft_functions. (Except in my case, I was calling ft_selectdata_new directly).
Eelke Spaak - 2013-01-19 15:01:04 +0100
I agree with Johanna, the cfg passed to ft_selectdata should be the one which is put in the dataout.cfg, with dataout.cfg.previous being the one used for ft_freqanalysis (in this example). This also ensures ft_selectdata is compatible with the whole provenance/pipeline thingy.
Robert Oostenveld - 2013-01-21 11:58:31 +0100
(In reply to comment #2) in cfg=[]; cfg.avgoverfreq='yes'; freqfa=ft_selectdata_new(cfg,freq); freqa.cfg should indeed be from ft_selectdata_new. It is something the user did. But if you do cfg=[]; cfg.avgoverfreq='yes'; stat=fr_freqstatistics(cfg,freq); then stat.cfg should be the used-cfg from fr_freqstatistics. That fr_freqstatistics is using ft_selectdata_new internally should not be visible to the user. But if the user explicitly does cfg=[]; cfg.avgoverfreq='yes'; freqfa=ft_selectdata_new(cfg,freq); cfg = []; stat=fr_freqstatistics(cfg,freq); then stat.cfg should the used-cfg from fr_freqstatistics and stat.cfg.previous the used cfg-from ft_selectdata_new.
Jörn M. Horschig - 2013-03-12 10:55:33 +0100
I guess it is safe to assume that only ft_ prefixed functions calling ft_selectdata should end up in the .cfg?
Robert Oostenveld - 2013-03-12 11:28:31 +0100
(In reply to comment #5) no. When you give it N inputs, the output contains N+1 fields with the last one being the updated cfg. Items such as cfg.channel, cfg.toi, etc should be updated according to the actual selection of the data. E.g. think of its (intended/projected) use in ft_freqgrandaverage(cfg, subj1, subj2, ...) which starts with ft_selectdata, which does the following for all subjects make the same selection and subsequently in the remainder of ft_freqgrandaverage you just add the matrices, knowing that they match. So the ft_freqgrandaverage delegates the responsibility for data selection, but the user still needs to know what cfg settings were actually used.
Jörn M. Horschig - 2013-03-12 11:41:50 +0100
sorry, I was distracted while writing ;) What I wanted to ask was the following: Should ft_selectdata only end up in data.cfg if it is called by an ft_ prefixed function, or is there a case in which a not ft-prefixed function calls ft_selectdata and the .cfg should still be updated?
Eelke Spaak - 2013-03-12 11:49:37 +0100
(In reply to comment #7) I think the idea is that ft_selectdata_new does NOT end up in the cfg whenever it is being called by a fieldtrip function, and DOES end up in the cfg when it is called by a non-fieldtrip function (i.e. user's own scripts/functions). So, kind of the other way around from what I understand from your question :) Would there be cases where fieldtrip code calls ft_selectdata from a non-ft_-prefixed function? E.g. from a /private/ function? If so, maybe do a check on the caller's path instead, if that's possible. (Note that ft_version can return the FT path as second output argument, if I recall correctly.)
Robert Oostenveld - 2013-03-12 13:26:23 +0100
(In reply to comment #8) > Would there be cases where fieldtrip code calls ft_selectdata from a > non-ft_-prefixed function? No, I don't think so. Or even more specific: I don't expect ft_selectdata to be called from low- and intermediate-level functions, but only high-level(*) functions. *) High-level is here defined as being part of the list fieldtrip/*.m and having a cfg as first input argument. Medium and low is the rest
Robert Oostenveld - 2013-03-12 13:30:07 +0100
(In reply to comment #8) > I think the idea is that ft_selectdata_new does NOT end up in the cfg whenever > it is being called by a fieldtrip function, and DOES end up in the cfg when it > is called by a non-fieldtrip function (i.e. user's own scripts/functions). I think it should show up when being called by a ft_function. Otherwise the user cannot see the defaults that were imposed by ft_selectdata_new (e.g. cfg.channel=all, which then translates to the whole list). To the end user it should not matter whether ft_timelockgrandaverage is doing the bookkeeping itself (now), or whether it delegates the bookkeeping to ft_selectdata (future).