spec: imprecise language around min and max when considering NaN

[btracey]

The go spec at tip has the following language about min and max

For numeric arguments, min and max are commutative and associative:

min(x, y)    == min(y, x)
min(x, y, z) == min(min(x, y), z) == min(x, min(y, z))

In my reading, this is insufficiently precise. In particular, min(math.NaN()) == min(math.NaN()) is false, so currently the spec is impossible to satisfy (cannot both propogate NaN and have those expressions be true). There should be a clarification around the interaction of NaN and ==.

[mknyszek]

CC @griesemer who wrote the spec update for this.

[griesemer]

NaN which stands for "Not a Number" is not a number, and thus arguably not a numeric argument...

[gopherbot]

Change https://go.dev/cl/500416 mentions this issue: spec: clarify min/max rules for numeric arguments (exclude NaNs)

[btracey]

NaN is why we can't have nice things (and arguably floating point numbers more generally)

…

On Fri, Jun 2, 2023, 5:22 PM Robert Griesemer ***@***.***> wrote: NaN which stands for "Not a Number" is not a number, and thus arguably not a numeric argument... — Reply to this email directly, view it on GitHub <#60570 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA4CUW4Q52M4O3FA4AYMMETXJIHNHANCNFSM6AAAAAAYYF4T5I> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[crisman]

This is already covered in the text given, "For numeric arguments" which means NaN is not covered in that section.

The next line after the original quoted text gives the chart:

For floating-point arguments negative zero, NaN, and infinity the following rules apply:

Also min(math.NaN()) == min(math.NaN()) is correct as math.NaN() == math.NaN() is false and the spec says "Two floating-point values are compared as defined by the IEEE-754 standard." and that is how 754 works. We can't import 754 like that and then say using it in another section is broken.

[crisman]

Meh, my brain is clearly not up to speed as float64 is numeric and NaN is float64 so my last comment does not make sense. Sorry about the added confusion.

[crisman]

Related oddity for NaN in #60616.