List/Array/Seq.max/min/maxBy/minBy may return nan if the sequence starts with nan

The position where NaN appears changes what Seq.max returns.

Repro steps

printfn $"{Seq.max [nan; 2.; 1.; 4.]}"
printfn $"{Seq.max [3.; nan; 1.; 4.]}"
printfn $"{Seq.max [3.; 2.; nan; 4.]}"
printfn $"{Seq.max [3.; 2.; 1.; nan]}"

Expected behavior

4
4
4
3

Actual behavior

NaN
4
4
3

Known workarounds

Filter away all NaNs first.

Related information

SharpLab https://sharplab.io/#v2:DYLgZgzgNALiBOBXAdgHwA7wJbJmZABACQBEA3gMoCmAjgHQC2AhgB4EDayTyA3AQEx0+ARiEEALHQC6AXxIBYAFCYceQqUq1GrDgGYxXXgVF9Jshcuy58xctXrM27fX0F9Dp6XKUrr6u1qOemJuxgbc5kA=

[tannergooding]

seemingly making NaN the lowest number, so it only affects Min, not Max.

Missed this bit. This does seem like a bug and an undesirable one at that. If someone is willing to log an issue, then we should probably look at this and make a determination.

[abelbraaksma]

@edgarfgp, I’ve taken that on, see #13558. So far I’ve only added tests, but that by and of itself exhibited some behavior that may need addressing.

Min is weird one, seems NaN is always lowest.

@dsyme/@vzarytovskii, considering that .NET as a whole is moving to more conformance towards IEEE 754:2019, I think it’s probably best not to mimic the bug from LINQ. Besides, if that one in particular relies on Math.Min, there’s https://github.com/dotnet/runtime/pull/70865 by @tannergooding, which fixes that behavior.

My understanding is min and max should return NaN in all four cases.

That’s also my understanding. It would otherwise be quite surprising w.r.t. the basic rule with NaN: if either operand is NaN, return NaN.