feat: add class_names support to Precision and Recall metrics

[aniketpandey05]

Fixes #1466

Description:
Adds an optional class_names parameter to _BasePrecisionRecall, allowing compute() to return a labeled dict instead of an unnamed tensor when average=False or average=None. Useful for per-class metric tracking where knowing which score belongs to which class matters for logging and visualization.

Check list:

• New tests are added (if a new feature is added)
• New doc strings: description and/or example code are in RST format
• Documentation is updated (if required)

[aaishwarymishra]

ok so like wont this code break fbeta metric when precision and recall have average=False and they have class_names, we need to update the fbeta too to support this.

There can be more metrics that can benefit from this change. I am not sure though.

[aniketpandey05]

@aaishwarymishra would raising errors for those condition a better option or should we add full class_name support to fbeta

[aaishwarymishra]

I am not sure, adding support for the class names in fbeta would be easier, but fbeta uses the MetricsLambda for overloading operator we can update them, I am not sure @vfdev-5 what you think would be appropriate?

[steaphenai]

Could we please clarify Fbeta behavior when class_names is used with average=False/None

[vfdev-5]

I am not sure, adding support for the class names in fbeta would be easier, but fbeta uses the MetricsLambda for overloading operator we can update them, I am not sure @vfdev-5 what you think would be appropriate?

If we can compute F1 score per class than we should propagate the dict structure until the output of the F1 otherwise, take .values() of the dict output from precision and recall.

[aniketpandey05]

Hey @vfdev-5 , would adding a helper in metric.py to handle dict arithmetic in all operator overloads so the dict propagates through to the Fbeta output be a good approach? Also when average=True and class_names is set, should Fbeta return a scalar float or propagate the dict as is?

[vfdev-5]

Hey @vfdev-5 , would adding a helper in metric.py to handle dict arithmetic in all operator overloads so the dict propagates through to the Fbeta output be a good approach? Also when average=True and class_names is set, should Fbeta return a scalar float or propagate the dict as is?

I do not know, what would you suggest? Let's try to make it the most simple possible and intuitively clear.

[aniketpandey05]

hey @vfdev-5 I think Fbeta should return a per-class dict if class_names is set, regardless of average.

[vfdev-5]

@rogueslasher ok, let's implement that this way and see if this works as expected

[aniketpandey05]

Hey @vfdev-5, would adding a _dict_aware_op helper in metric.py and updating all operator overloads to use it for element-wise dict arithmetic, and skipping average in fbeta.py when class_names is set be a good idea? It touches all operator overloads in metric.py which affects all metrics.

i am worried since it touches all operators overloads

[aniketpandey05]

@aaishwarymishra ,would love your help in this can you look into it more please

[aaishwarymishra]

@rogueslasher well , I am not sure to be honest i wont touch the metric operators as it kind of affect every metric, for a case which can be only relevant for very few metrics, I think we should modify Fbeta directly.

[aniketpandey05]

@aaishwarymishra the header rules and other three preview checks are taking insane amount of time . is there any issue

[aaishwarymishra]

Documentation issue :)

[aniketpandey05]

@aaishwarymishra

[aaishwarymishra]

I think its from the conflict you forgot to resolve

[aaishwarymishra]

I think you should try to pre-commit we recently moved from the black formatter to ruff, that may be the reason for docstring problem but not sure.

[aaishwarymishra]

There should be tests for recall too