core min and max should behave predictably when args include NaN

contagious ok

The contagious version of the patch seems to me the right approach, assuming fidelity to Java (e.g. Math/max and Math/min) is the standard.

This implements the third variant described above with one difference:

When when all arguments are NaN we don't throw a exception, but return NaN instead.

(min) and (max) still throw an exception, however.

This fell out of the implementation naturally and I couldn't see a good reason to prefer one behavior to another.

CLJ-868-contagious-NaN.patch

(Implementation corresponds to variant 2 from my earlier comment.)

It seems to me that there are four approaches one might take to address this.

1. Document the current undefined behavior of min and max in the presence of NaN.

2. Define that min and max will return NaN if any argument is NaN.

3. Define that min and max will ignore any NaN arguments.

4. Define that min and max will throw an exception if any argument is NaN.

1 Document current behavior as undefined

This requires no changes in the implementation, but it doesn't strike me as a desirable resolution. Why unnecessarily codify clearly confusing behavior?

2 Make NaN contagious

Define min and max to return NaN if and only if at least one of their arguments is NaN. This seems most in keeping with the (admittedly perverse) behavior of NaN as specified.

See JLS 4.2.4 Floating Point Operations:

An operation that overflows produces a signed infinity, an operation that underflows produces a denormalized value or a signed zero, and an operation that has no mathematically definite result produces NaN. All numeric operations with NaN as an operand produce NaN as a result. As has already been described, NaN is unordered, so a numeric comparison operation involving one or two NaNs returns false and any != comparison involving NaN returns true, including x!=x when x is NaN.

3 Let min and max ignore NaN arguments

This means that (min a NaN b) would be exactly equivalent to (min a b). It would further imply that (min NaN) would be equivalent to (min), which currently throws an exception.

4 Let NaN cause min and max to throw an exception

Currently min and max throw an exception if given arguments that are not Numeric. One might plausibly argue that NaN is not numeric.