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

0 votes
in Java Interop by

The clojure.core/mod function works just as expected for small positive floating-point dividend and small positive integer divisor. But today I was working on some edge case tests and came across the following inexplicable behavior:

`
user=> (def big Double/MAX_VALUE)

'user/big

user=> (mod big 10)
0.0
user=> (mod big 100)
0.0
user=> (mod big 1000)
1.9958403095347198E292
user=> (mod big 999)
-Infinity
user=> (mod big 998)
0.0
user=> (mod big 997)
1.9958403095347198E292
user=> (mod big 996)
0.0
user=> (mod big 995)
0.0
user=> (mod big 994)
0.0
user=> (mod big 1001)
1.9958403095347198E292
user=> (mod big 1002)
0.0
user=> (mod big 1003)
0.0
user=> (mod big 1004)
-Infinity
user=> (mod big 1005)
0.0
`

No idea whether this is inherited from a Java bug. I can see nothing special about the values chosen, and I suspect if one scanned it'd be easy to find other glitches.

4 Answers

0 votes
by

Comment made by: alexmiller

{{mod}} is based on {{rem}} - from a glance, {{mod}} does not seem to account properly for any case of overflow, and I suspect that's at the root of a lot of these problems.

0 votes
by

Comment made by: gfredericks

Test.check suggests (mod 6.7772677936779424E16 23) => -8.0 is somewhat close to minimal.

0 votes
by

Comment made by: vaguery

Actually, just checked, and {{rem}} gives the same results. Thus {{(rem Double/MAX_VALUE 1001)}} is {{1.9958403095347198E292}}, and (rem 6.7772677936779424E16 23) => -8.0.

0 votes
by
Reference: https://clojure.atlassian.net/browse/CLJ-1960 (reported by alex+import)
...