Detector components (costs, scores etc.) as classes

[Tveten]

Goal: Unify the detector components. Make them safer. Make the extension pattern simpler and clearer.

See #23 for discussions.

New features:

• The BaseIntervalScorer class, inheriting from sktime.BaseEstimator. Public methods:

  • fit(self, X, y=None) -> self
  • evaluate(self, cuts: ArrayLike) -> np.ndarray

• Four sub base classes inheriting from BaseIntervalScorer:

  • skchange.costs.BaseCost. Expects 2 columns in cuts: start, end.
  • skchange.change_scores.BaseChangeScore. Expects 3 columns in cuts: start, split, end.
  • skchange.anomaly_scores.BaseSaving. Expects 2 columns in cuts: start, end.
  • skchange.anomaly_scores.BaseLocalAnomalyScore: Expects 4 columns in cuts: outer_start, inner_start, inner_end, outer_end.

• Classes for automatically converting costs to any of the three other score classes.

• Convenience functions allowing either costs or an appropriate score to be used as input to all the detectors.

All existing functionality is implemented within the new design + additions.

[Tveten]

Naming decision:

• Rename BaseIntervalEvaluator to BaseIntervalScorer based on discussion with @fkiraly

• Rename the intervals argument to .evaluate to cuts based on offline discussion with @johannvk .

  • intervals suggests the input should be two entries (start, end], and hides the potential splitting info.
  • splits suggests the whole data should be split in two or more parts, and hides the interval subsetting info.
  • cuts is a word that can cover both interval subsetting and splitting. It's up to each sub base class to define what the cuts mean and how they are used internally during .evaluate.