You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
BinaryClassificationMetrics is not sealed - but equivalent classes for regression and multiclass are #2769
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.
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.
Activity
codemzs commentedon Feb 27, 2019
Hi @vinodshanbhag , This is because
CalibratedBinaryClassificationMetricsinheritsBinaryClassificationMetrics. Is this causing any issues for you?TomFinley commentedon Feb 27, 2019
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 commentedon Feb 27, 2019
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 sinceRunResult<T>is not publicly constructable -- I imagine a constraint is strictly not necessary.codemzs commentedon Feb 27, 2019
@vinodshanbhag Ok, sounds good, can you please close this bug if you think it is resolved?
APIs for reversed binary operators (dotnet#2769)
Move DataFrame to machinelearning (#5641)
Merge from main repository (#1)
Actually merge from main (#2)
Update editor config and format samples (#5893)