fix(asr): keep the digit "0" in convert_num_to_words (WER groundtruth cleaning)

[harjothkhara]

What does this PR do ?

Fixes a silent word-drop in convert_num_to_words(): a standalone "0" token is deleted instead of becoming "zero", which corrupts groundtruth text (and the WER denominator) during evaluation.

Collection: ASR (nemo/collections/asr/parts/utils/eval_utils.py)

Changelog

• convert_num_to_words builds each number digit-by-digit with while num:. When a token is the bare string "0", num = 0 is falsy, so the loop body never runs and the token produces no output — it is silently dropped. Every other digit works, and "0" embedded in a larger number ("10", "100") works because the loop is entered by the nonzero leading digit.
• This is reached by default in WER evaluation: clean_label(_str, num_to_words=True, ...) defaults num_to_words=True and is applied to the reference in cal_write_wer(..., clean_groundtruth_text=True). So a reference like "the answer is 0" becomes "the answer is" — the reference loses a word, changing both its content and the WER/CER denominator.
• Fix: emit "zero" explicitly for the num == 0 case; all other inputs are unchanged (minimal, behavior-preserving). Note: leading-zero handling ("007" -> "seven") is a separate pre-existing quirk and is intentionally left untouched to keep this change single-purpose.

Usage

from nemo.collections.asr.parts.utils.eval_utils import convert_num_to_words, clean_label

convert_num_to_words("the answer is 0")   # before: "the answer is"        after: "the answer is zero"
convert_num_to_words("5 0 3")             # before: "five  three"          after: "five  zero three"
clean_label("The answer is 0")            # before: "the answer is"        after: "the answer is zero"

Before your PR is "Ready for review"

Pre checks:

• Make sure you read and followed Contributor guidelines
• Did you write any new necessary tests? — added tests/collections/asr/utils/test_eval_utils.py
• Did you add or update any necessary documentation? — n/a (internal bugfix)
• Does the PR affect components that are optional to install? — no

PR Type:

• New Feature
• Bugfix
• Documentation

Additional Information

• Self-found (no pre-existing issue). Verified GPU-free: the fix is pure string logic; the new test compares on tokens (robust to the function's pre-existing internal spacing) and fails on the old code, passes on the fix. I don't have a CUDA machine so I confirmed pass/fail with a standalone replica of the function; the in-repo test runs as a normal CPU unit test in CI.

[copy-pr-bot]

This pull request requires additional validation before any workflows can run on NVIDIA's runners.

Pull request vetters can view their responsibilities here.

Contributors can view more details about this message here.