Why `Double.Min(nan, -1.) = nan` and `Double.Max(nan, -1.) = nan`?

[64J0]

Please provide a succinct description of the issue.

I just noticed this weird behavior when comparing nan with doubles.

But, when I try using the Array.min, it gives the "correct" result (which is inconsistent):

Repro steps

1. Start fsi;

> open System;;
> Double.Min(nan, -1.);;
val it: float = nan

> Double.Max(nan, -1.);;
val it: float = nan

> let testArray : double array = [| 0.0; nan; 0.0; 0.0; 0.0; -0.3814976554; -0.0; 0.0 |];
val testArray: double array =
  [|0.0; nan; 0.0; 0.0; 0.0; -0.3814976554; -0.0; 0.0|]

> Array.min(testArray);;                                                                 
val it: double = -0.3814976554

Expected behavior

I was expecting that a number would be always bigger and less than any nan.

What is the rationale for the other way around?

Actual behavior

It's informed at the repro steps section.

This happens when using System.Numerics.Vector too:

Known workarounds

Related information

Provide any related information (optional):

• Operating system: Linux
• .NET Runtime kind (.NET Core, .NET Framework, Mono): .NET 10
• Editing Tools (e.g. Visual Studio Version, Visual Studio): -

[tannergooding]

Min and Max implement the IEEE 754 minimum and maximum operations, respectively. These require that -0 < +0 and that NaN is always propagated out (i.e. Min(5, NaN) and Max(5, NaN) both return NaN)

MinNumber and MaxNumber implement the minimumNumber and maximumNumber operations. These require that -0 < +0 and that the non-NaN value is propagated out (i.e. Min(5, NaN) and Max(5, NaN) both return 5)

The *Magnitude and *MagnitudeNumber functions operator much the same way (and implement corresponding IEEE 754 functions), but they compare the absolute values and return the input with the larger magnitude (i.e. MinMagnitude(-5, 2) returns 2; while MaxMagnitude(-5, 2) returns -5 because it compares abs(-5) vs abs(2)).

The *Native functions do not correspond to IEEE 754 functionality and instead rather implement hardware specific functionality. They correctly behave for most inputs, but do not guarantee the behavior of -0 vs +0 or number vs NaN. It will be dependent on the underlying hardware and whatever is "most efficient". -- So, for these special edge cases, an AVX512 capable machine may see different behavior from an AVX2 capable machine, which may see different behavior from an Arm64 machine, etc.

[tannergooding]

The Math.*, double.*, and float.* APIs do not correspond to F#. They are general .NET functions and so questions about them typically belong on dotnet/runtime.

The Array.min and related functions are specific to F# and questions about them belong here.

Some extensions like Enumerable.Min are also specific to .NET in general. Such APIs may have their own logical requirements, such as using IComparable rather than operator < or operator >. Typically this is necessary to ensure stable sorting or correct usage with APIs like GetHashCode (dictionaries, hashsets, maps, etc) because they have much stricter requirements than a type may provide for compliance with their own specs (like IEEE 754)

[64J0]

Thanks for the detailed reply @tannergooding.

The *Native functions do not correspond to IEEE 754 functionality and instead rather implement hardware specific functionality. They correctly behave for most inputs, but do not guarantee the behavior of -0 vs +0 or number vs NaN. It will be dependent on the underlying hardware and whatever is "most efficient". -- So, for these special edge cases, an AVX512 capable machine may see different behavior from an AVX2 capable machine, which may see different behavior from an Arm64 machine, etc.

I see, so there's no way to grant that the min implementation from SIMDArray will behave the same way as the F# Array.min, since the former depends on the machine where the code is running, and the latter doesn't.

At least not with this current SIMDArray implementation.

[tannergooding]

Correct. You wouldn't want SimdArray to match either, just as you wouldn't want TensorPrimitives.Min to match what Enumerable.Min from LINQ does. The APIs have different goals and considerations.

-- Also worth noting it doesn't look like SimdArray depends on the machine, at least not exactly. While Vector.Min has historically just been implemented as (x < y) ? x : y, it was updated in .NET 10 to always match Math.Min in behavior. You have Vector.MinNative for cases where you want it to be "fast" and don't care about the handling of edge case values.

In general, for the .NET Libraries at least and especially moving forward, the numeric APIs will continue to be explicit about matching behavior. However, collection APIs will typically continue to be implemented in terms of IComparable unless it is a scenario that warrants other support also existing.

[64J0]

Got it, might be a limitation related to the TFM configuration for this project (currently netstandard2.1). My IDE only shows this:

When I change it to net10.0 I get much more options:

[64J0]

Using Vector.MinNumber (after updating the TFM to net10.0) made it pass the tests generated with FsCheck.

[64J0]

More info:

• Setting net10.0 as the TFM I believe is not an option for the SIMDArray Library project (due to old versions compatibility), so we can't use the Vector.MinNumber;
• The tests fail if we use net10.0 as their TFM, but they work using net8.0. I believe this is related to the net10.0 changes that you mentioned:

  [...] it was updated in .NET 10 to always match Math.Min in behavior.

So, Array.SIMD.min is expected to have the same result as Array.min up til net8.0.

*Using net9.0 I already got some errors running the tests and comparing the results of Array.SIMD.min and Array.min.

[tannergooding]

Setting net10.0 as the TFM I believe is not an option for the SIMDArray Library project (due to old versions compatibility), so we can't use the Vector.MinNumber;

You can always multi-target: <TargetFrameworks>net8.0;net10.0</TargetFrameworks> and then do:

#if NET10_0_OR_GREATER
    minV <- Vector.MinNumber(v, minV)
#else
    minV <- Vector.Min(v, minV)
#endif

You can also isolate this to your own helper method or extension if that was desired, that way you could avoid repeating ifdefs in more than one location. -- Noting that NET10_0_OR_GREATER and friends are automatically defined by the SDK: https://learn.microsoft.com/en-us/dotnet/standard/frameworks#preprocessor-symbols

[64J0]

Indeed, I'll try this approach. Thanks for sharing @tannergooding.