Hello everyone,

Good idea! Okay, here are some initial thoughts for discussion. In the context of output types, I’m considering anomalies and segments as the same, except segments must partition the index. Some specific examples that come to mind:

Example 1. A binary anomaly indicator

feature1_anomalies_ = [(start1,end1), (start2,end2)…]
is a more compact way to denote some binary anomaly indicator which could equivalently be represented as
feature1_anomalies_ = np.array([True, False, True, True, …])
The mask representation though, does make it explicit if there are missing index values, which might be helpful.

Question 1: would we consider a class of standardised outputs? We could have ^these both defined as standardised Outputs() with helper functions to map between them? (inheriting the index information from somewhere).

Example 2. Multiple anomaly types {‘A’, ‘B’,…}

feature1_anomalies_ = {‘A’: [(start11,end11), (start21,end21)…], ‘B’:[(start12,end12), (start22,end22)…], …}
or
feature1_A_ = np.array([True, False, True, True, …])
feature1_B_ = np.array([False, True, False, False…])
…
or
feature1_ = np.array([‘A’, ‘B’, ‘A’, ‘A’ …])

Example 3. Rolling windows

Some algorithms have rolling windows as inputs, or we can input a feature (like ewma) to any anomaly algorithm, so I guess with a window size k=2 we have something like
feature1_A_ = np.array([None, None, True, False, True, True, …])
feature1_B_ = np.array([None, None, False, True, False, False…])
or
feature1_ = np.array([None, None, ‘A’, ‘B’, ‘A’, ‘A’ …])
(not sure about mixing None and different dtypes in a mask, a bad idea probably)

Example 4. Reducing the outputs of the features

Some algorithms look at a multivariate timeseries and output a combined assessment of the system (like intrinsic dimensionality). Input would be n_row x n_col and output has shape n_row x 1. Maybe an algorithm tag {per_feature=False}? The output would be of the same form as in Example 1.

Any more examples? Thoughts on the above?

Cheers!

That sounds really reasonable^^

This BaseAnnotator will cover both anomaly detection tasks and segmenting tasks, right?

In the first case, it's clear to me how boolean/float values describe outliers/anomalies

e.g. X = [1, 2 ,3 ,100, 2] -> output = [False, False, False, True, False] or as float (scores).

But how would we describe segments?

e.g. X = [1, 2 ,3 ,100, 102] -> output = [0,0,0,1,1] (incrementing floats? up until K?)

(lazy notation, I don't mean they are lists, imagine them as pd.DataFrame or np.array)

(Copying my comment (and Mirae's reply) because I used incorrect account for my contribution.)

I think first thing to do is pin down (in writing) what we want the input and output formats to be, and what learning tasks we intend to cover, before deciding on the nitty gritty of implementation details and where input checks will live.

My preferences for input output types:

• General preference for being consistent with other parts of sktime. However, happy to explore alternative designs and compare pros and cons.

• Input types.

  • (uni or multivariate) series. pandas dataframe following sktime conventions that already exist
  • (uni or multivariate) panel. do we need this straightaway? if not, then skip. Otherwise, might have to use some the input conversion functionality that exists in forecasting (because different algorithms may have different assumptions about panel data. e.g. all have same columns or not)

• Output type.

  • at least in early stages, preference for single output mtype. happy to go with the 'dense' format. If input is dataframe X, then output is dataframe with same index as X. I do not know enough about future plans to say if we want to restrict output to have one column, or if we want to restrict the type of the values (binary or float or ...).
  • have various conversion utilities available in case users want to convert between different output types for their use case. e.g. going from dense to sparse, or going from dense to 'pandas interval index format'

• learning tasks

  • i have preference for sticking with unsupervised and non-panel tasks.
  • in future, when we include broader range of tasks, will need to introduce tag system (or equivalent alternative) to deal with multiple kinds of learning tasks.

• quick thoughts on mirae's comments above

  • i had quick skim of current annotation base class, and there are not yet any checks or conversions related to dense/format. As far as I can see, the only checks that exist are that inputs should follow the 'Series scitype' used everywhere else in sktime, which I think is a reasonable restriction.
  • letting future developers decide what input or output checks they want in their algorithms has two downsides in my mind. First, if developers can choose what checks they do, then we cannot enforce uniform interfaces. Second, if we do somehow enforce uniform interfaces, then it means developers have to copy and paste a lot of code.