gabenespoli / phzlab Goto Github PK

For bar plots, add an option to automatically calculate t-tests for each pair of bars and put significance stars on the plot.

Note: 'summary' works with 'all', but not individual parameters e.g., 'participant'

FFTStry = phz_writetable(PHZ, 'feature', 'fft100', 'region', 'target', 'FFRsummary', 'efr', 'summary', {'participant', 'session'})
Calculating features...

Feature 1/1: fft100
Restricted to 'target [0.06 0.17]' region.
Summarized data by 'participant session'.
Extracted feature 'fft100'.
Index exceeds matrix dimensions.

Error in phz_discard (line 80)
PHZ.lib.tags.(field) = PHZ.lib.tags.(field)(keep);

Error in phz_summary (line 135)
TMP = phz_discard(TMP, false); % verbose = false

Error in phz_feature (line 352)
[PHZ, preSummaryData] = phz_summary(PHZ,keepVars,verbose);

Error in phz_writetable (line 173)
[s,featureTitle] =
phz_feature(PHZ,feature{i},'summary',keepVars,'region',region,'verbose',verbose);

The reason for this in the comments says:

% (run phz_summary through phz_feature because fft feature needs to average
% over the summaryType by participant before doing the fft)

This needs to be removed to allow the user to insert processing in between feature and summary, or to do them in a different order.

By doing the preprocessing at the same time as parsing varargin, it is impossible to adjust the values of a preset on the fly. Instead, varargin should simply log the values of the preprocessing, as well as their order, and then apply them later. This means that we can overwrite a value from a preset.

However, one big issue with this is that you may want to use the preset value AS WELL as a new value, like using subset twice for example.

If length(varargin) is odd then assume the first arg is preset. This is so that you could specify processing before the preset, and after the preset. Currently, with the requirement that the first arg is the preset, no processing can be dynamically inserted before the preset.

phz_plot and phz_writetable would probably also have to look for these 2's.

Or forget about a default. This is in the docs but not actually implemented.

These parameters should work the same way that they do in phz_plot.

Since phzABR has been changed to phzFFR, this needs to be reflected in all code. noted in phz_combine, line 141: TMP = phzABR_equalizeTrials(TMP, equalGrpVar, verbose);

change to phzFFR_equalizeTrials -- I haven't checked to see whether there are any other similar issues.

Use PHZ.lib.tables.(tablename) to store presets for tables, just like PHZ.lib.plots. Could also try and conflate this with PHZ.lib.plots.

This is to harmonize the experience of using param/value pairs and doing things manually in the command window. This means that region, feature, and summary will no longer wait until all other processing to be applied. They will be sensitive to order.

Hi Gabe,

When using phz_writetable, I am running into an issue when I define the parameter value pair 'region','target' and 'feature','snr'. It says that the region is invalid (which I don't think is true because if I type PHZ.region, target appears in the list), as well as the feature is an unknown feature. I tried debugging right before the error appears, and it doesn't seem that PHZ.region is being cleared out, so I'm not entirely sure what is happening.

Screenshot of the error attached. If you'd like to play with a data file you can find one under Emily's folder called combined.phz. PS this error happens with single and combined files.

Let me know what you think