Lightning-AI / Lightning-AI/torchmetrics
BinaryMatthewsCorrCoef behaves inconsistently when denominator = 0
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 2.5k
- Forks
- 526
- Avg merge
- 6d 11h
- Merged PRs (30d)
- 5
Description
Bug: BinaryMatthewsCorrCoef behaves inconsistently when denominator = 0
Hi, I came across an inconsistency in BinaryMatthewsCorrCoef while testing edge cases and wanted to check whether this is intended behavior.
Minimal Example
import torch
from torchmetrics.classification import BinaryMatthewsCorrCoef
from sklearn.metrics import matthews_corrcoef
metric = BinaryMatthewsCorrCoef()
def test_case(preds, targets):
tm = metric(preds, targets).item()
sk = matthews_corrcoef(targets.numpy(), preds.numpy())
return tm, sk
# Case 1: all negatives
preds = torch.zeros(10)
targets = torch.zeros(10)
print(test_case(preds, targets))
# TorchMetrics: 1.0, sklearn: 0.0
# Case 2: degenerate mixed
preds = torch.zeros(10)
targets = torch.tensor([0,0,0,1,1,1,1,1,1,1])
print(test_case(preds, targets))
# TorchMetrics: -0.276..., sklearn: 0.0
# Case 3: near-trivial
preds = torch.tensor([1] + [0]*9)
targets = torch.tensor([0]*10)
print(test_case(preds, targets))
# TorchMetrics: ~0.84, sklearn: 0.0
Observation
The discrepancy appears specifically when the MCC denominator is zero (i.e., degenerate confusion matrices).
In these cases:
sklearnreturns0.0torchmetricsreturns values such as1.0or other non-zero floats depending on the configuration
I observed this consistently across randomized tests; all mismatches traced back to these zero-denominator cases.
For context, this was identified during differential testing against a reference implementation based on a formally specified definition of these metrics, which helped isolate the behavior.
Question
Since MCC is mathematically undefined when the denominator is zero, different conventions are possible.
However, the current behavior does not seem to clearly align with:
- the common convention used by sklearn (
0), or - a rule-based alternative (e.g., mapping to {1, 0, -1} depending on the case)
Is this behavior intentional? If so, could you clarify the convention being followed here?
Options
- Align with sklearn (
return 0when denominator = 0), or - Clearly document the intended behavior for these cases
- Optionally expose a
zero_division-style parameter for flexibility
Happy to provide additional test cases or help explore a fix if useful. Thanks!
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reproducing the three minimal examples with BinaryMatthewsCorrCoef and compare their zero-denominator results with sklearn's matthews_corrcoef. Trace the metric's denominator-zero behavior and determine whether the intended outcome is a fix or documentation; done means the convention is implemented consistently and covered for the shown degenerate cases.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python, pytorch, scikit-learn
- Domain
- machine-learning
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 45/100