decorator problem in mass when re-routing to non-normalized function

[NimaSarajpoor]

I recently noticed that there is a need to provide the name of arguments in mass function if I want to set normalize=False.

In other words, I cannot simply do:

T, sliding_mu, sliding_std = core.preprocess(T, m)
dist_profile = core.mass(Q, T, sliding_mu, sliding_std, normalize=False)

This gives me the following error:

TypeError                                 Traceback (most recent call last)
~\AppData\Local\Temp/ipykernel_8412/711003992.py in <module>
      1 T, sliding_mu, sliding_std = core.preprocess(T, m)
      2 Q = T[0:0+m]
----> 3 dist_profile = core.mass(Q, T, sliding_mu, sliding_std, normalize=False)

~\anaconda3\lib\site-packages\stumpy\core.py in inner_wrapper(*args, **kwargs)
    136                             else:
    137                                 kwargs[v] = kwargs.pop(k)
--> 138                 return non_norm(*args, **kwargs)
    139 
    140         return inner_wrapper

~\anaconda3\lib\site-packages\stumpy\core.py in mass_absolute(Q, T, T_subseq_isfinite, T_squared)
   1102             T_squared = np.sum(rolling_window(T * T, m), axis=-1)
   1103         distance_profile[:] = _mass_absolute(Q_squared, T_squared, QT)
-> 1104         distance_profile[~T_subseq_isfinite] = np.inf
   1105 
   1106     return distance_profile

TypeError: ufunc 'invert' not supported for the input types, and the inputs could not be safely coerced to any supported types according to the casting rule ''safe''

And, instead I should do:

T, sliding_mu, sliding_std = core.preprocess(T, m)
dist_profile = core.mass(Q, T,  M_T=sliding_mu, Σ_T=sliding_std, normalize=False)

Is that by design? because, as a user, it is hard for me to type Σ_T and I have to copy it.

(NOTE: I know M_T and Σ_T are not used in core._mass_absolute. I have no problem with using mass_absolute. I merely wanted to let you know of such behavior)

[NimaSarajpoor]

@seanlaw
Btw, I took a look at the docstring of non_normalized and, according to the example provided, it seems we should provide the name of arguments. However, I was wondering if there is a way round this matter.

[seanlaw]

Note that when normalize=True, passing T_subseq_isfinite in as a parameter would/should cause core.mass to raise an error

[seanlaw]

Added new issue #637 to track this

[seanlaw]

I'm not trying to pat myself on the back here as I couldn't remember "why" I had designed the decorator this way. However, this repeated issue actually helps me recall "why" and it seems to be working as intended and only requires adding a note to our docstring(s) without changing any code to accomodate. 😄

[NimaSarajpoor]

I'm not trying to pat myself on the back here as I couldn't remember "why" I had designed the decorator this way

:D

However, this repeated issue actually helps me recall "why" and it seems to be working as intended and only requires adding a note to our docstring(s) without changing any code to accomodate.

And, again, we can see the importance of having a good docstring. I am now appreciating the great effort that has been put into making good docstrings in STUMPY. I recently started contributing to tslearn package (improve KNN by using dtw lb_keogh and I thought it can prepare me for SWAMP paper). The problem is that its docstring, in my opinion, is not good! I had to follow codes and keep them in mind to understand the parameters! So, I think writing a good docstring is VERY important! Thanks for your effort!

[seanlaw]

Yeah, the most important thing really is documentation AND unit testing. IMHO, it really doesn't make sense to focus on developing new features when the docs and tests are bad. This is my personal bias. Unfortunately, building new features is wayyy more fun than writing docs and tests and this latter part can be a thankless job.