BinaryClassificationMetrics is not sealed - but equivalent classes for regression and multiclass are

[vinodshanbhag]

Inconsistency in API extensibility -- see title

[codemzs]

Hi @vinodshanbhag , This is because CalibratedBinaryClassificationMetrics inherits BinaryClassificationMetrics. Is this causing any issues for you?

[TomFinley]

As @codemzs points out this is deliberate. We generally don't have unsealed non-abstract or non-static classes anywhere in our API, but this seemed relatively harmless, especially since it is impossible to extend from it in any meaningful way anyway (given that its constructor is not part of the public surface). Plus we did need to distinguish between the two types of metrics it was possible to get out of a binary classifier.

We could adopt the potentially more principled though somewhat more awkward position of having an abstract base class shared by both, and having the non-calibrated metrics just descend from it and be otherwise empty, but it would be nice to understand how it is causing you difficulty first.

[vinodshanbhag]

It is not a problem for automl -- just happen to notice it while exploring 'below' and assumed it is an overlook. Didnt know about CalibratedBinary metrics before today....

Automl API return type is a collection of RunResult<T> where T is either of BinaryMetrics, MulticlassMetrics or RegressionMetrics -- so I was exploring whether i can enforce a meaningful constraint on T but since RunResult<T> is not publicly constructable -- I imagine a constraint is strictly not necessary.

[codemzs]

@vinodshanbhag Ok, sounds good, can you please close this bug if you think it is resolved?