Proposed documentation enhancement
CSP and SPoC classes of the decoding module both have a fit, transform, and fit_transform method, which require passing in 3D data of shape (n_epochs, n_channels, n_times). The docstrings for fit and transform are customised for each class, describing the shape of the data properly.
However, the fit_transform method uses the docstring from the TransformerMixin class, which only refers to data as needing shape (n_samples, n_features). The inconsistent description of the parameters could lead to confusion in how to use the classes, e.g.: https://mne.discourse.group/t/spoc-with-fit-transform-x-must-have-at-least-3-dimensions/9147.
This could be avoided by having a docstring for fit_transform that is specific for the data shapes expected by the CSP and SPoC classes.
The SSD class also uses the default fit_transform docstring, but in this case it does accept 2D arrays as data. It's slightly less misleading here, but perhaps also worth changing.
What do others think?
Proposed documentation enhancement
CSPandSPoCclasses of thedecodingmodule both have afit,transform, andfit_transformmethod, which require passing in 3D data of shape(n_epochs, n_channels, n_times). The docstrings forfitandtransformare customised for each class, describing the shape of the data properly.However, the
fit_transformmethod uses the docstring from theTransformerMixinclass, which only refers to data as needing shape(n_samples, n_features). The inconsistent description of the parameters could lead to confusion in how to use the classes, e.g.: https://mne.discourse.group/t/spoc-with-fit-transform-x-must-have-at-least-3-dimensions/9147.This could be avoided by having a docstring for
fit_transformthat is specific for the data shapes expected by theCSPandSPoCclasses.The
SSDclass also uses the defaultfit_transformdocstring, but in this case it does accept 2D arrays as data. It's slightly less misleading here, but perhaps also worth changing.What do others think?