ComprehensiveFCParameters: cwt_coefficients

[erjans]

Hi!

Thanks for the great library! This is my first GitHub discussion, so please correct me if I'm not following any standards.

In my current project, I have found one possible flaw or drawback which could be interesting to address. It revolves around the default choice for parameters in the cwt_coefficients in ComprehensiveFCParameters.

"cwt_coefficients": [
    {"widths": width, "coeff": coeff, "w": w}
    for width in [(2, 5, 10, 20)]
    for coeff in range(15)
    for w in (2, 5, 10, 20)

Here, w is considered the width of the wavelet (related to frequency) and coeff is related to time.

The value for the cwt_coefficients is extracted by the function cwt_coefficients in the tsfresh.feature_extraction.feature_calculators module. From my understanding, this function calculates the CWT using scipy.signal.cwt for all time points in the signal x. Afterwards, it simply saves the coefficient of interest into the res list by indexing the result from the CWT calculation.

To my understanding, using coeff in range(15) will result in taking only the first 15 coefficients. In my case, my time series are ~1600 time points, meaning that I miss the majority of the extracted CWT components.

I believe a better solution would be to let coeff be evenly spaced across the length of the input instead, so as not to miss the majority of possible important CWT features.

Please let me know if I've understood something incorrectly.

[nils-braun]

Hi @erjans!
Welcome :)
In principle, a very reasonable idea. However, the defaults of the feature extractor settings are chosen once, before we see any data. We do this to make the use-cases with a train and test split simpler as well as to simplify our own library code. So we can not choose the defaults according to the data (length).
However, it is indeed a good practice to adjust the feature extraction settings using additional knowledge on your data, e.g. the size/any special features you expect/the resolution etc.
So what you described could indeed make sense for your use-case!