TensorPrimitives.MinNumber(ReadOnlySpan<T>) incorrectly propagates NaN

[Sebtous]

Description

TensorPrimitives.MinNumber(ReadOnlySpan<T>) returns NaN when any element of the span is NaN, even when other elements are numbers.

This appears inconsistent with MinNumber semantics, where a numeric operand should be preferred over NaN.

Reproduction Steps

using System;
using System.Numerics.Tensors;

float[] values = [1f, float.NaN, 2f];

Console.WriteLine(float.MinNumber(1f, float.NaN));
Console.WriteLine(TensorPrimitives.MinNumber(values));

Output:

1
NaN

Expected behavior

TensorPrimitives.MinNumber(values) should return:

1

A NaN should be ignored when another numeric value is available, consistent with float.MinNumber / T.MinNumber.

If all elements are NaN, returning NaN would be expected.

Actual behavior

TensorPrimitives.MinNumber(values) returns NaN as soon as the reduction encounters a NaN.

Regression?

Unknown

Known Workarounds

Perform the reduction manually using T.MinNumber:

T result = values[0];

for (int i = 1; i < values.Length; i++)
{
    result = T.MinNumber(result, values[i]);
}

Configuration

• .NET 10
• Appears to be independent of OS and architecture.

Other information

The scalar reduction overload currently delegates to:

MinMaxCore<T, MinNumberOperator<T>>(x)

However, MinMaxCore contains explicit T.IsNaN(...) checks that return the encountered NaN immediately. This prevents MinNumberOperator<T>, which delegates to T.MinNumber(x, y), from applying MinNumber semantics.

MaxNumber(ReadOnlySpan<T>) appears to use the same reduction mechanism and may be affected by the equivalent issue.

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-system-numerics
See info in area-owners.md if you want to be subscribed.

[geiltonxavier]

I would like to take this on. My plan: give the aggregation operator a trait that says whether it propagates NaN, and have MinMaxCore skip its NaN early exit when it does not. That fixes MinNumber, MaxNumber, MinMagnitudeNumber and MaxMagnitudeNumber while Min, Max and the plain Magnitude variants keep their behavior. The Half path already goes through short and looks correct. I will add reduction tests with NaN in the middle, at the start and all NaN.

Does that direction sound right?