Back to the main page.
Bug 2715 - ft_math: suggestions for improvement
| Status | CLOSED FIXED |
| Reported | 2014-09-30 12:32:00 +0200 |
| Modified | 2015-01-12 09:20:02 +0100 |
| Product: | FieldTrip |
| Component: | core |
| Version: | unspecified |
| Hardware: | PC |
| Operating System: | Mac OS |
| Importance: | P5 normal |
| Assigned to: | Jan-Mathijs Schoffelen |
| URL: | |
| Tags: | |
| Depends on: | |
| Blocks: | |
| See also: |
Jan-Mathijs Schoffelen - 2014-09-30 12:32:37 +0200
I was looking into the possibility to use cfg.operation in combination with cfg.scalar, where cfg.scalar is a matrix ;-). Purpose: doing a bias correction on a TFR power spectrum according to e.g. Bokil et al J Neurosci Methods 20067: m = repmat(shiftdim(freq.dof./2,-1),[numel(freq.label) 1 1]); powspctrm_biascorrected = log(freq.powspctrm) - psi(m) + log(m); The idea here would be that m has the same size as freq.powspctrm, but is not scalar (because it may vary over time). I can get this to work with: cfg.operation = 'log(x1)-psi(s)+log(s)'; cfg.scalar = m; in combination with a small hack around line 237: if isscalar(s) y = arrayfun(... elseif size(s)==size(arginval{1}) y = feval(operation, arginval{:}); end This is of course not uber-nice because strictly speaking cfg.scalar is not scalar anymore. Shall we build in support for non-scalar cfg.scalar (and call it cfg.matrix)? I think it should be do-able if we explicitly require this field to have the same size as the data.(cfg.parameter). Along the way I noticed that cfg.scalar is not touched and lost to posterity in the output.cfg. Although ugly, I suggest to touch it (if user-defined) around line 177
Robert Oostenveld - 2014-09-30 20:43:38 +0200
agreed (cfg.matrix) and agreed (touching them for posterity). I suggest to keep cfg.matrix outside of the regular documentation.