Back to the main page.

Bug 2578 - extend ft_math with (a-b)/(a+b) and more fancy stuff

Reported 2014-05-14 13:41:00 +0200
Modified 2016-06-14 16:14:48 +0200
Product: FieldTrip
Component: core
Version: unspecified
Hardware: PC
Operating System: Windows
Importance: P5 normal
Assigned to: Robert Oostenveld
Depends on:
Blocks: 1617
See also:

Jan-Mathijs Schoffelen - 2014-05-14 13:41:13 +0200

(Robert here): perhaps we can even do an eval/regexp type of operation. Besides implementing this, it would be important to extend the documentation. Eg is subtract presently implemented as a-b or b-a? a syntax like cfg.operation = '(x1-x2)/(x1+x2)' would be nice.

Robert Oostenveld - 2014-05-14 17:08:30 +0200

mac011> svn commit ft_math.m test/test_ft_math.m Sending ft_math.m Sending test/test_ft_math.m Transmitting file data .. Committed revision 9524. mac011> svn commit ft_math.m Sending ft_math.m Transmitting file data . Committed revision 9525. @eelke and jorn, could you have a look at the present implementation? Better not try to understand the actual code (I am proud of the functionality, not how it looks), but please do check that the interface is how you would like it to be.

Robert Oostenveld - 2014-05-14 17:10:15 +0200

(In reply to Robert Oostenveld from comment #1) PS getting the implementation to work on all possible inputs (single, two, three, with/without additional scalar, numeric array or cell-array) was not trivial and I do hope that the present code will work on other MATLAB versions than the one I used here (2014a).

Eelke Spaak - 2014-06-01 09:54:44 +0200

(In reply to Robert Oostenveld from comment #1) Looks good to me! One thing I don't get is why the 'scalar' option exists; we could also specify cfg.operation = 'x1/6' right? I tested this, it works. Another question that arose: why does cfg.operation = 'x1/x2' work, doesn't it need to be x1 ./ x2? Nowhere in ft_math do I see a call to vectorize().

Robert Oostenveld - 2014-06-01 11:25:56 +0200

(In reply to Eelke Spaak from comment #3) cfg.scalar works because it was implemented before the equation parsing was implemented. I agree that it is better to use the new functionality and remove the old from the documentation. Also the "divide" etcetera operations are better replaced by the more explicit new handling. Or at least start with the equation parsing in the help and not have it at the end. the x1/x2 works because it is mapped to a local function (@operation) which is then evaluated with arrayfun. This has the (intended) limitation that it is always element wise and that the output is always the same size as the input. If that weer not the case, the description of the data elements (label, time, freq) would fall apart.

Jörn M. Horschig - 2014-06-03 10:09:54 +0200

looks also great to me, nice! I would also be in favor of documenting the option to use e.g. x1/6. How about catching an error around the call to arrayfun (line 249) and throw a more intuitive error for the user. Right now, errors look like this: Undefined function or variable 'y2'. Error in ft_math/@(x1)log(x1/y2) Error in ft_math (line 249) y{i} = arrayfun(operation, arginval{:}); It would be nicer for the user to get an error "the specified string-operation is invalid"

Robert Oostenveld - 2015-11-10 16:26:39 +0100

(In reply to Jörn M. Horschig from comment #5) I updated the documentation. Cleaner error handling is too much work. mac011> svn commit ft_math.m Sending ft_math.m Transmitting file data . Committed revision 10862.

Robert Oostenveld - 2016-06-14 16:14:48 +0200

Hereby I am closing multiple bugs that have been resolved for some time now. If you don't agree to the resolution, please reopen.