min-key and max-key should return NaN if any of the argument is NaN

Question

It appears that min-key and max-key behave incorrectly (following Java that follows IEEE floating point convention):

(apply max-key last [[:a 10000] [:b (/ 0. 0)] [:c 0]]) [:c 0]

Not sure how this should then propagate forward, but definitely not silently. Options:

1. (link: :b NaN) (the first item to generate the NaN)
2. NaN (this is changing the expected type)
3. ArithmeticException Operation with at least one NaN operand.

If this was to be patched the same as it was for min/max (http://dev.clojure.org/jira/browse/CLJ-868) it will probably result in option 1.

Answer 1

Comment made by: nicholasantonov

This implements the first solution of a contagious NaN in the same style as (link: http://dev.clojure.org/jira/browse/CLJ-868 text: CLJ 868)

Answer 2

Comment made by: alexmiller

Patch should have tests...

Answer 3

Comment made by: nicholasantonov

This latest patch adds tests for min-key and max-key with and without NaN results, as there were none before.

Answer 4

Comment made by: alexmiller

This overlaps with CLJ-99, which has already been prescreened. I would like to base whatever changes this patch requires over the top of that ticket. To build this, apply the CLJ-99 patch, then branch, make you changes, and then create a patch relative to the clj-99 branch. Sorry that's a pain - usually patches don't collide at this level of conflict.

Answer 5

Comment made by: nicholasantonov

The latest patch fixes min and max key in the same way, but based over CLJ-99, only evaluating the function once for each item.

Answer 6

Reference: https://clojure.atlassian.net/browse/CLJ-1911 (reported by reborg)