Back to the main page.
Bug 1097 - discuss the remove flag in ft_redefinetrial, possibly reimplement
| Status | CLOSED FIXED |
| Reported | 2011-11-02 08:48:00 +0100 |
| Modified | 2012-07-12 10:40:57 +0200 |
| Product: | FieldTrip |
| Component: | core |
| Version: | unspecified |
| Hardware: | PC |
| Operating System: | Mac OS |
| Importance: | P1 enhancement |
| Assigned to: | Jan-Mathijs Schoffelen |
| URL: | |
| Tags: | |
| Depends on: | |
| Blocks: | |
| See also: |
Robert Oostenveld - 2011-11-02 08:48:35 +0100
Hoi Thijs, Ik zie in ft_redefinetrial een onduidelijke afhandeling van de situatie "elseif ~isempty(cfg.trl)" waarin met een data en een dataold en een remove flag wordt gewerkt. Dat moet volgens mij wel wat strakker kuinnen. Het gaat om het stukje op regel 262 if remove && isfield(data, 'trialinfo') data = rmfield(data, 'trialinfo'); end en de code in de bovenstaande "for iTrl" loop. Zoals ik het zie is de remove flag niet nodig. Of trialinfo wordt toegevoegd, en dan moet 'ie blijven, of hij wordt niet toegevoegd en dan hoeft 'ie ook niet weg. Mee eens?
Jan-Mathijs Schoffelen - 2011-11-02 08:59:39 +0100
Hmmm. goede vraag. Het lijkt dat dit ooit wel om een bepaalde reden geimplementeerd is... Die 'remove' wordt op true gezet zo gauw er een cfg.trl verwacht wordt die moet worden samengesteld uit meer dan 1 oorspronkelijke input trial. Waarschijnlijk zoiets als: -sampleinfo oorspronkelijke data: [1 1000; 1001 2000]; -verlangde trl [501 1500 0]; Uit de code lijkt, alsof dit mogelijk is (maar is dit ook zo?). In zo'n geval is het onduidelijk waar de trialinfo vandaan moet komen, en in dat geval lijkt het me het meest veilig om hem maar weg te keilen.