Share your thoughts in the 2024 State of Clojure Survey!

Welcome! Please see the About page for a little more info on how this works.

0 votes
in Clojure by

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.

6 Answers

0 votes
by

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)

0 votes
by

Comment made by: alexmiller

Patch should have tests...

0 votes
by

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.

0 votes
by

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.

0 votes
by

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.

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