Back to the main page.
Bug 925 - ft_freqcomparison documentation is not clear
Status | CLOSED FIXED |
Reported | 2011-09-03 16:49:00 +0200 |
Modified | 2011-09-14 14:33:35 +0200 |
Product: | FieldTrip |
Component: | documentation |
Version: | unspecified |
Hardware: | PC |
Operating System: | Mac OS |
Importance: | P1 normal |
Assigned to: | Arjen Stolk |
URL: | |
Tags: | |
Depends on: | |
Blocks: | |
See also: |
Robert Oostenveld - 2011-09-03 16:49:46 +0200
- in what sense is this function different from ft_freqbaseline? - does it compare conditions (in stead of activation v.s. baseline)?
Arjen Stolk - 2011-09-03 17:37:48 +0200
Yes, it (In reply to comment #0) > - in what sense is this function differrom ft_freqbaseline? > - does it compare conditions (in stead of activation v.s. baseline)? Yes, it does compare two conditions instead of one with its own baseline. shall I make a more general function that does the same at the sourcelevel? Or is the functionality to trivial to be in the toolbox?
Robert Oostenveld - 2011-09-03 17:54:33 +0200
please document the function. Right now from the help it is not clear what it does. Furthermore, the role of the only(?) cfg option in the processing is not clear, does it baselinecorrect prior to the comparison?
Arjen Stolk - 2011-09-07 11:41:50 +0200
(In reply to comment #2) > please document the function. Right now from the help it is not clear what it > does. Furthermore, the role of the only(?) cfg option in the processing is not > clear, does it baselinecorrect prior to the comparison? The help is updated. The distinction with ft_freqbaseline is made more clear. Also the input config option 'cfg.baselinetype' has been modified to 'cfg.comparisontype' to further elaborate on this discrepancy.