Clojure

<= is incorrect when args include Double/NaN

Details

  • Type: Defect Defect
  • Status: Reopened Reopened
  • Priority: Trivial Trivial
  • Resolution: Unresolved
  • Affects Version/s: Release 1.6
  • Fix Version/s: None
  • Component/s: None
  • Labels:
  • Environment:
    Mac OS X, Java 6
  • Patch:
    Code and Test
  • Approval:
    Vetted

Description

user=> (<= (long Double/NaN) 1)
true     
user=> (<= Double/NaN 1)
false  ;; should match primitive version

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.

Patch: 738.diff, 738-tests.diff

Screened by:

  1. 738.diff
    26/Aug/11 11:33 AM
    4 kB
    Luke VanderHart
  2. 738-tests.diff
    26/Aug/11 11:33 AM
    3 kB
    Luke VanderHart

Activity

Alexander Taggart made changes -
Field Original Value New Value
Waiting On richhickey
Aaron Bedra made changes -
Fix Version/s Release.Next [ 10038 ]
Affects Version/s Release 1.2 [ 10037 ]
Priority Critical [ 2 ] Minor [ 4 ]
Rich Hickey made changes -
Waiting On richhickey
Luke VanderHart made changes -
Assignee Luke VanderHart [ lvanderhart ]
Luke VanderHart made changes -
Status Open [ 1 ] In Progress [ 3 ]
Luke VanderHart made changes -
Attachment 738.diff [ 10321 ]
Attachment 738-tests.diff [ 10322 ]
Luke VanderHart made changes -
Status In Progress [ 3 ] Resolved [ 5 ]
Resolution Completed [ 1 ]
Patch Code and Test
Stuart Halloway made changes -
Status Resolved [ 5 ] Closed [ 6 ]
Alex Miller made changes -
Approval Vetted [ 10003 ]
Assignee Luke VanderHart [ lvanderhart ]
Status Closed [ 6 ] Reopened [ 4 ]
Resolution Completed [ 1 ]
Alex Miller made changes -
Fix Version/s Release 1.3 [ 10038 ]
Alex Miller made changes -
Description user> (<= 10 Double/NaN 1)
true

(on both 1.2 and 1.3 alpha 5).
{code}
user=> (<= 10 (long Double/NaN) 1)
false
user=> (<= 10 Double/NaN 1)
true ;; should match primitive version
{code}

*Cause:* The problem was that our 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.

*Patch:* 738.diff, 738-tests.diff

*Screened by:*
Affects Version/s Release 1.3 [ 10038 ]
Affects Version/s Release 1.6 [ 10157 ]
Alex Miller made changes -
Labels math
Alex Miller made changes -
Description {code}
user=> (<= 10 (long Double/NaN) 1)
false
user=> (<= 10 Double/NaN 1)
true ;; should match primitive version
{code}

*Cause:* The problem was that our 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.

*Patch:* 738.diff, 738-tests.diff

*Screened by:*
{code}
user=> (<= (long Double/NaN) 1)
true
user=> (<= Double/NaN 1)
false ;; should match primitive version
{code}

*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.

*Patch:* 738.diff, 738-tests.diff

*Screened by:*
Alex Miller made changes -
Priority Minor [ 4 ] Trivial [ 5 ]

People

Vote (1)
Watch (6)

Dates

  • Created:
    Updated: