Refactor metrics into its own module

[alejoe91]

This PR includes a major refactor of the metrics concept.

It defines a BaseMetric, with core metadata of individual metrics including dtypes, column names, extension dependance, and a compute function.
Another BaseMetricExtension contains a collection of BaseMetrics and deals with most of the machinery, including:

• setting params
• checking dependencies and removing metrics based on it
• computing metrics
• deleting, merging, splitting metrics
• preparing data that can be shared across metrics (e.g., pca for pca metrics, peaks info and templates for template metrics)

The template_metrics, quality_metrics, and a new spiketrain_metrics extensions are now in the metrics module. The latter only includes num_spikes and firing_rate, which are also imported as quality metrics.

Still finalizing tests, but this should be 90% done

[chrishalcrow]

Hello, this is a new thing. It'd be great to check if we can compute this before we try to do it, for the following situation:

Suppose you originally compute a metric using spikeinterface version 103 (or some fork that you've made yourself... ahem).
Then you open your analyzer in si-gui using version 102. There was a new metric introduced in 103, which 102 doesn't know about. When you try to merge, it errors because it can't compute the new metric. So you do any merging at all due to the inability to merge one metric.
Or you no longer have the recording when you open, so you can't compute sd_ratio or something....

Instead, I'd like to warn if we can't compute and stick in anan. We could could do that here by checking that metric_names are in self.metric_list.

[chrishalcrow]

Oh, I think I meant to write this at line 1207 about the merging step, but also applies to splits!

[chrishalcrow]

Nag nag nag

[alejoe91]

Same here:

available_metric_names = [m.metric_name for m in self.metric_list]
metric_names = [m for m in self.params["metric_names"] if m in available_metric_names]

[chrishalcrow]

This looks great - love the prepare_data idea! And this refactor will make it less awkward to develop new metrics. And the pca file is much neater now - nice.

I think this is a good chance to remove compute_{metric_name} stuff from the docs (modules/qualitymetrics) and replace with analyzer.compute("quality_metrics", metric_names={metric_name}) as our recommended method. More awkward, but much better for provenance etc.

I'd vote to take the chance to make multi channel template metrics included by default: they're very helpful.

[alejoe91]

I'd vote to take the chance to make multi channel template metrics included by default: they're very helpful.

I agree! Maybe we can make it default for number of channel > 64?

[chrishalcrow]

I don't get the deprecation warning if I do e.g.

from spikeinterface.qualitymetrics import compute_quality_metrics

Because of some import * magic. This should fix it in almost all cases:

if __name__ not in ('__main__', 'builtins'):
    warnings.warn(
        "The module 'spikeinterface.qualitymetrics' is deprecated and will be removed in 0.105.0."
        "Please use 'spikeinterface.metrics.quality' instead.",
        DeprecationWarning,
        stacklevel=2,
    )

[chrishalcrow]

cough cough

[chrishalcrow]

This will error if we don't know how to compute the metrics in metric_names. So if a metric changes name between version, we get an error and can't merge/split. I think we should only give _compute_metrics the intersection of metric_names and self.metric_list?

[chrishalcrow]

Thoughts??

[alejoe91]

This should work:

available_metric_names = [m.metric_name for m in self.metric_list]

metric_names = [m for m in self.params["metric_names"] if m in available_metric_names]

[chrishalcrow]

Yeah, sounds good to me