Clojure Q&A - Recent questions tagged math

.pow bigdec vs bigint

Sat, 26 Jul 2025 09:15:29 +0000

Consider this:

user> (.pow (bigdec 2) 3)
8M

user> (.pow (bigint 2) 3)
Execution error (IllegalArgumentException) at foo/eval10898 (REPL:1093).
No matching method pow found taking 1 args for class clojure.lang.BigInt

Is that an intentional choice in the language?

Note that this works:

user=> (.pow (biginteger 2) 3)
8
user=> (type (.pow (biginteger 2) 3))
java.math.BigInteger

Except the type is not clojure.lang.BigInt, but java.math.BigInteger, which are different types.

clojure.math/scalb docstring error

Sat, 11 Nov 2023 13:08:46 +0000

The docstring for scalb links to the documentation for nextDown, presumably just a mistake.

It links here: https://docs.oracle.com/javase/8/docs/api/java/lang/Math.html#nextDown-double-

But should link here: https://docs.oracle.com/javase/8/docs/api/java/lang/Math.html#scalb-double-int-

clojure.math/floor docstring error

Mon, 30 Oct 2023 12:55:24 +0000

In the docstring for clojure.math/floor it says:

If a is less than zero but greater than -1.0 => -0.0

but that's obviously not true:

(math/floor -0.3)
;; => -1.0

I guess it was intended to add that line to the docstring of clojure.math/ceil but added it to floor by mistake?

Some corner cases that might be considered bugs in Ratio implementation

Sun, 30 Jan 2022 02:24:18 +0000

I was looking through the new clojure.core/abs implementation on type Ratio, and it seemed that there is an assumption in the code that uses the internal details of type clojure.lang.Ratio that the denominator is always positive (e.g. see the definitions of isNeg and isPos methods for type Ratio).

I started looking for cases where that assumption might be violated, and found the following, all of which might be distinctive to values of type Ratio produced by an expression with Long/MIN_VALUE as the denominator and an integer with type Long or smaller as the numerator:

$ clj -Sdeps '{:deps {org.clojure/clojure {:mvn/version "1.11.0-alpha4"}}}'
Clojure 1.11.0-alpha4

user=> (/ 1 Long/MIN_VALUE)
-1/-9223372036854775808
user=> (< (/ 1 Long/MIN_VALUE) 0)         ;; This gives correct numerical answer
true
user=> (< (* 1 (/ 1 Long/MIN_VALUE)) 0)        ;; This does not
false
user=> (abs (/ 1 Long/MIN_VALUE))            ;; Gives incorrect numerical answer
1/-9223372036854775808
user=> (< (abs (/ 1 Long/MIN_VALUE)) 0)        ;; correct numerical answer
false
user=> (< (* 1 (abs (/ 1 Long/MIN_VALUE))) 0)       ;; incorrect numerical answer
true

I have carefully checked other occurrences of Ratio in source file Numbers.java in Clojure's implementation, and as far as I can tell the only issue is with the method named divide in the LongOps class. If that method avoided this problem by checking for the special case when the numerator and/or denominator is equal to Long/MIN_VALUE and behaved a little differently in that case, I do not see any other bugs.

Here is another issue if the numerator is equal to Long/MIN_VALUE, where the root cause is in the same LongOps divide method:

user=> (/ Long/MIN_VALUE -3)   ;; should return positive value, but returns negative value
-9223372036854775808/3
user=> (< (/ Long/MIN_VALUE -3) 0)
true

Should other math wrappers be considered?

Wed, 26 Jan 2022 19:35:54 +0000

With the java.lang.Math operations all being wrapped, then is it also desirable to do the same with the operations static methods on Double and Long?

Some of these functions have simple Clojure(Script) implementations. For instance, Double/isNaN can be achieved with #(identical? ##NaN %) but it seems that if the language works with values like ##NaN, then there should be a built-in way of recognizing it. (I note that some people may not realize that #(= ##NaN %) will not work).

Each of these functions can also be implemented in ClojureScript. This was demonstrated while reimplementing the clojure.math namespace for ClojureScript, since many of these methods from Long and Double were needed.