Added numeric_limits for matx types

[cliffburdick]

No description provided.

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

[cliffburdick]

/build

[greptile-apps]

Greptile Summary

This PR adds cuda::std::numeric_limits specializations for all matx extended-precision types: matxFp16, matxBf16, their complex variants, and fltflt. The previously-flagged missing has_denorm/has_denorm_loss fields are now present in all four specializations, and fltflt::denorm_min() correctly uses the single-argument float constructor (preserving the |hi| >= |lo| invariant).

Confidence Score: 5/5

Safe to merge; all previously-flagged P1 issues are resolved and only a minor convention suggestion remains.

All concerns from the prior review thread (missing has_denorm/has_denorm_loss fields, incorrect fltflt denorm_min invariant) have been addressed. The only remaining finding is a P2 style suggestion about setting both NaN components in fltflt::quiet_NaN/signaling_NaN. No P0 or P1 issues remain.

include/matx/kernels/fltflt.h — minor NaN-initialization convention issue on lines 748-749.

Important Files Changed

Filename	Overview
include/matx/core/half.h	Adds cuda::std::numeric_limits specializations for matxFp16 and matxBf16; uses bit_cast from the layout-compatible __half/__nv_bfloat16 for all value-returning methods. All previously-flagged fields (has_denorm, has_denorm_loss) are now present.
include/matx/core/half_complex.h	Adds cuda::std::numeric_limits specializations for matxFp16Complex and matxBf16Complex; delegates all scalar fields to the underlying matxFp16/matxBf16 limits. signaling_NaN() correctly uses the two-arg matxHalf constructor to avoid float round-trip that would quiet the sNaN.
include/matx/kernels/fltflt.h	Adds cuda::std::numeric_limits specialization for fltflt. denorm_min() correctly uses the single-float constructor. quiet_NaN/signaling_NaN set both components to NaN, which is unconventional (hi=NaN, lo=0 is the typical convention).

Class Diagram

%%{init: {'theme': 'neutral'}}%%
classDiagram
    class `numeric_limits~matxFp16~` {
        +_Base = numeric_limits~__half~
        +bool is_specialized
        +float_denorm_style has_denorm
        +bool has_denorm_loss
        +min() matxFp16
        +max() matxFp16
        +epsilon() matxFp16
        +denorm_min() matxFp16
    }
    class `numeric_limits~matxBf16~` {
        +_Base = numeric_limits~__nv_bfloat16~
        +bool is_specialized
        +float_denorm_style has_denorm
        +bool has_denorm_loss
        +min() matxBf16
        +max() matxBf16
        +epsilon() matxBf16
        +denorm_min() matxBf16
    }
    class `numeric_limits~matxFp16Complex~` {
        +_ScalarLimits = numeric_limits~matxFp16~
        +bool is_specialized
        +min() matxFp16Complex
        +signaling_NaN() matxFp16Complex
    }
    class `numeric_limits~matxBf16Complex~` {
        +_ScalarLimits = numeric_limits~matxBf16~
        +bool is_specialized
        +min() matxBf16Complex
        +signaling_NaN() matxBf16Complex
    }
    class `numeric_limits~fltflt~` {
        +bool is_specialized
        +int digits = 48
        +float_denorm_style has_denorm = denorm_present
        +min() fltflt
        +max() fltflt
        +epsilon() fltflt
        +denorm_min() fltflt
    }
    `numeric_limits~matxFp16~` --> `numeric_limits~matxFp16Complex~` : delegated by
    `numeric_limits~matxBf16~` --> `numeric_limits~matxBf16Complex~` : delegated by

Loading

_{Reviews (5): Last reviewed commit: "Fix signaling_NaN per code review" | Re-trigger Greptile}

[cliffburdick]

/build

[coveralls]

Coverage is 91.749% — numeric_limits_overload into main. No base build found for main.