Cause: The problem was that the logic for lte/gte depended on the fact that lte is equivalent to !gt.
However, in Java, this assumption is invalid - any comparison involving NaN always yields false.
Solution: The fix was to adding lte and gte methods to Numbers.Ops directly, rather than implementing everything in terms of lt. This was the only fix I could see that didn't incur the cost of runtime checks for NaN.
Screened by: Alex Miller
Mac OS X, Java 6
Might want to make the "Fix Version" on this ticket empty so it is back on the JIRA state chart as Vetted.
Patch clj-738-v2.diff is identical in content to Luke's 2 patches 738.diff and 738-tests.diff, and includes them both, retaining his authorship. The only change is to a few context lines so that the new patch applies cleanly to latest master, whereas the older patches did not.
While the patch looks good and tests all pass, the example listed in the ticket description did not actually change behavior with the patch?
The ticket description has a typo (long, not double) – sorry. The first comment has a real test case.
user> (<= 1000 (Double. Double/NaN))
user> (<= 1000 (double Double/NaN))
Doh! Thank you. I'm the one that introduced it too.