Incorrect `rem` behavior between clojure.lang.BigInt, Double

Mon, 22 Feb 2021 15:51:53 +0000

This is related to issue 1555, but the types at play are different, so the underlying problem might be different too.

rem seems to be returning very incorrect results between bigint and float. Note the large difference in using 10000 as the divisor vs 1e4:

user> (rem 9037601485536036300227801N 10000)
7801N
user> (long (rem 9037601485536036300227801N 1e4))
1073741824

test.check provides a tighter example of clearly incorrect results:

user> (rem 9007199254740993N 2)
1N
user> (rem 9007199254740993N 2.0)
0.0

Here's a generative test to reproduce this result:

(clojure.test.check/quick-check
 100 (prop/for-all [l gen/size-bounded-bigint
                    r (gen/fmap inc gen/nat)]
                   (== (rem l (double r))
                       (rem l (long r)))))

Why do BigInt literals not require N suffix, but BigDecimals do?

Tue, 03 Sep 2019 19:28:00 +0000

I find it a bit inconsistent that I can type:

123423534634544234534634645342363462443649886756676645466767687

And it will auto-promote it to a BigInt to fit, without me needing to specify so with the N suffix.

But if using decimal:

12.3423534634544234534634645342363462443649886756676645466767687

It won't auto-promote to BigDecimal without explicitly adding an M suffix. Instead it'll truncate to double precision.

Any reason why that is?

Clojure Q&A - Recent questions tagged bigint

Incorrect `rem` behavior between clojure.lang.BigInt, Double

Why do BigInt literals not require N suffix, but BigDecimals do?