Why do DTW distance metrics behave differently?

[fergus-pick]

I am new to using sktime, I was wondering why the numba sktime.distances metric='dtw' gives a different output than the sktime.dists_kernels implementation for this case, yet the squared metric is identical?

from sktime.datasets import load_italy_power_demand
from sktime.dists_kernels import DtwDist
from sktime.distances import distance

X, _ = load_italy_power_demand(split="train", return_type="numpy3D")
dtw_dist = DtwDist()
dtw_dist(X[0], X[1])
distance(X[0], X[1], metric='dtw')
distance(X[0], X[1], metric='squared')

>>> [[4.88675167]]
>>> 2.2562779371935555
>>> 4.886751673604364

[fkiraly]

Update: I know what is going on, this is not a bug.

dtw_dist is a pairwise distance, so expects - consistently with all other panel data estimators - input in one of the sktime Panel formats, e.g., numpy3D with (n_instance, n_variable, n_timepoints).

So, if you pass dtw_dist(X, X), you will get a matrix where the (0,1)-the and (1,0)-th element are, as expected, 2.256etc.

I am not sure why it runs with 2D numpy, it seems to assume a single instance with 24 variables and 1 time point. For which the DTW distance is the same as the squared distance, if the inner distance (on scalars) is squared euclidean.

That would explain the behaviour?

---

Old post (incorrect)

Hm, that is curious. DtwDist should be a direct interface to distance.

However, upon closer inspection, DtwDist interfaces pairwise_distance, which internally has different code to distance, but both claim to be the same (up to a loop).
My guess is that one of the two is buggy, this seems like a mixup between numpy 2D, numpy 3D, index order or formatting or the like.

Do you perchance know which one is correct? We could calculate "squared" maually.
Also, the internal relevant code from pairwise_distance vs distance, below:

pairwise_distance:

    from sktime.distances._numba_utils import (
        _compute_pairwise_distance,
        _make_3d_series,
    )

    _x = _make_3d_series(x)
    if y is None:
        y = x
    _y = _make_3d_series(y)
    symmetric = np.array_equal(_x, _y)
    _metric_callable = _resolve_metric_to_factory(
        metric, _x[0], _y[0], _METRIC_INFOS, **kwargs
    )

distance:

    from sktime.distances._numba_utils import to_numba_timeseries

    _x = to_numba_timeseries(x)
    _y = to_numba_timeseries(y)

    _metric_callable = _resolve_metric_to_factory(
        metric, _x, _y, _METRIC_INFOS, **kwargs
    )

[fkiraly]

In case you wonder why there are so many, this is a collection of representations different developers within sktime and adjacent packages have been using to represent "collections of time series" aka Panel abstract data type.

To integrate all under a unified interface without having to rewrite dozens of different locations, we went with a converter/representation architecture hidden in the boilerplate layer.

[fkiraly]

then is the behavior of the below code unusual

I think your assumed specification is not what it is. According to the specification sheet:

• 3D numpy is (n_instances, n_variables, n_timepoints) (not n_instances, n_timepoints, n_variables) as you assume)
• 2D numpy is (n_instances, n_timepoints) (not (n_variables, n_timepoints) as you assume)

Somewhat unfortunantely, but I think there is no way around it, one interpretation of 3D and 2D numpy has to be enforced across all of sktime. There has been a lot of discussion of this in early days, but one can't interpret 3D numpy on way in one module and another way in another, same for 2D numpy.

[fkiraly]

tbh, I think the pd.DataFrame based representation is less confusing...

[fergus-pick]

Thanks for spending the time to explain this, it makes more sense now.

[fkiraly]

if you have any suggestions on how to improve either documentation of interface, these would be very welcome - especially if critical