Reject an explicit zero float width instead of the IEEE default

[SashaMIT]

Category:

Bug fix (non-breaking change which fixes an issue)

Description:

DType.parse("f32e8m0") came back as float32. DType.parse("f16e0m10") came back as float16.

The float constructor used width or default. A written 0 is falsy, so it was replaced with the IEEE default (23 significand bits, or 5 exponent bits). Those names are not registered DALI types. The parser now raises ValueError, the same as any other unknown name. Omitted widths still take the IEEE default, so f32 and f16 are unchanged.

Additional information:

Affected modules and functionalities:

nvidia.dali.experimental.dynamic.DType.parse and dtype().

Key points relevant for the review:

Only a missing width (None) takes the default. A written 0 stays 0, then fails the registered-type lookup.

Tests:

• Existing tests apply
• New tests added
  • Python tests
  • GTests
  • Benchmark
  • Other
• N/A

dali/test/python/experimental_mode/test_type.py: test_explicit_zero_float_field_is_not_replaced_with_the_default

On main the test fails because f32e8m0 is accepted as float32. With this change it passes.

Checklist

Documentation

• Existing documentation applies
• Documentation updated
  • Docstring
  • Doxygen
  • RST
  • Jupyter
  • Other
• N/A

DALI team only

Requirements

• Implements new requirements
• Affects existing requirements
• N/A

REQ IDs: N/A

JIRA TASK: N/A

[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.

[greptile-apps]

Confidence Score: 3/5

[Medium risk] Changes how float type parsing handles zero values.

The PR is not ready to merge because a rejected dtype name can be accepted on retry and the new validation message violates a repository requirement.

Findings

1.  Rejected dtype accepted on retry ▶
2.  Validation error lacks context ▶

Summary

The PR preserves explicitly written zero float widths and converts an unregistered-type lookup failure into ValueError.

• Adds tests for two zero-width names.
• Rejected names can be returned as unregistered types on a subsequent parse.

_{Reviews (1) · Last reviewed commit: "Reject an explicit zero float width inst..."}

[greptile-apps]

Rejected dtype accepted on retry Parsing f32e8m0 or f16e0m10 raises ValueError on the first call, but constructing the temporary DType has already cached it. A second dtype(name) call returns that unregistered type with type_id=None instead of rejecting it. Cache a parsed type only after its registered-type lookup succeeds, and test repeated calls.

[greptile-apps]

Validation error lacks context The new ValueError says only Unsupported type name: {name}. The repository’s error-message directive requires user-facing errors to identify the input, show expected versus actual values, and end as a complete sentence. This message gives no supported float widths or examples and lacks a final period; add that guidance so users can correct the name.

Rule Used: Error messages must name the affected parameter/operator, show expected vs. actual values, and end as a complete sentence. Not "is 5" but "got 5 channels, expected 1 or 3.". Use make_string(...) for C++ concatenation; f-strings in Python. (source)

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!