Lightning-AI / Lightning-AI/torchmetrics

BinaryMatthewsCorrCoef behaves inconsistently when denominator = 0

Open
#3,355 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

bug / fix help wanted
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:

  • sklearn returns 0.0
  • torchmetrics returns values such as 1.0 or 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 0 when 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

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.