fix(validation): correct argument validation in auroc, logauc, and pesq metrics

[AbdullahRasheed45]

Summary

Four more instances of the same and vs or logical operator bug in argument validation, affecting the AUROC, LogAUC, and PESQ metrics. These are the remaining sites not covered by PR #3440.

The Bug

Each guard uses and where or is required:

# Wrong: only raises when BOTH conditions are simultaneously True
if <type-check-fails> and <value-check-fails>:
    raise ValueError(...)

This means a value with a correct type but invalid range silently bypasses the check.

Files Changed

File	Parameter	Example of bypassed invalid input
audio/pesq.py	n_processes	n_processes=0 (int, but ≤ 0)
functional/classification/auroc.py	max_fpr	max_fpr=2.0 (float, but outside (0, 1])
retrieval/auroc.py	max_fpr	same as above in class API
functional/classification/logauc.py	fpr_range	fpr_range=[0.001, 0.1] (list of len 2, not tuple)

Reproduction

from torchmetrics.functional.classification import binary_auroc

# Before fix: no error for out-of-range max_fpr (silently computes wrong AUROC)
binary_auroc(preds, target, max_fpr=2.0)

# After fix:
# ValueError: Arguments `max_fpr` should be a float in range (0, 1], but got: 2.0

from torchmetrics.audio import PerceptualEvaluationSpeechQuality

# Before fix: no error for n_processes=0
PerceptualEvaluationSpeechQuality(fs=16000, mode='wb', n_processes=0)

# After fix:
# ValueError: Expected argument `n_processes` to be an int larger than 0 but got 0

Related

• PR fix(validation): correct 'and' to 'or' in argument validation across multiple metrics #3440 fixes the same bug pattern in specificity/precision/sensitivity, regression, group-fairness, and psnrb metrics.
• PRs bug fix validate top_k in multiclass classification metrics #3406 / fix(classification): validate top_k parameter for multiclass metrics #3416 / fix(retrieval): validate top_k parameter for RetrievalMAP and RetrievalMRR #3418 fix the same pattern for top_k in stat_scores and retrieval metrics.