3 ms·

You need to be familiar with Java types and differences between them (Integer, BigInteger) and how Math.pow() behaves with different types. This is more up to J

by dig1 5y ago

You need to be familiar with Java types and differences between them (Integer, BigInteger) and how Math.pow() behaves with different types. This is more up to Java, rather than Clojure. No need to pull the library for this, Clojure already has (biginteger) for that: user=> (.pow (biginteger 33) 33) 129110040087761027839616029934664535539337183380513

kazinator 5y ago
Didn't Clojure use the N suffix for big integers at one point? I don't see one on that output.
- jffry 5y ago
  The N suffix is for clojure.lang.BigInt, which are created with (bigint) which was added in Clojure 1.3 and still work to this day (I did these examples in the latest 1.10.3 release) user=> (bigint "129110040087761027839616029934664535539337183380513") 129110040087761027839616029934664535539337183380513N user=> (type *1) clojure.lang.BigInt The Java-platform bigint is java.lang.BigInteger which are created with (biginteger) which was added in Clojure 1.0. Printing one of these will not include an N suffix: user=> (biginteger "129110040087761027839616029934664535539337183380513") 129110040087761027839616029934664535539337183380513 user=> (type *1) java.math.BigInteger Clojure BigInts are supposed to involve less unboxing and therefore be more performant. If you provide an integer literal that's too large to fit in a java.lang.Long, the reader will use a BigInt instead: user=> 129110040087761027839616029934664535539337183380513 129110040087761027839616029934664535539337183380513N user=> (type *1) clojure.lang.BigInt user=> 12345 12345 user=> (type *1) java.lang.Long If all this seems like a mess, well it sort of is. Clojure has a very strong commitment to backwards compatibility, so when the Clojure-specific big int representation was added, the old JDK-based one was not removed, because the operations that the two support are different.
jffry 5y ago
Yeah if you know you're definitely dealing with integers that are large, and are willing to pay the cost to promote into biginteger territory, that's certainly a way to do it with the stdlib. The nice ergonomic thing about clojure.math.numeric-tower is you can shove any of the Clojure numeric types at it (longs, doubles, but also Ratio or BigNum etc) and it'll intelligently handle the various combinations of types in order to give you the best answer it can

by dig1 5y ago

kazinator 5y ago

Didn't Clojure use the N suffix for big integers at one point? I don't see one on that output.

jffry 5y ago
The N suffix is for clojure.lang.BigInt, which are created with (bigint) which was added in Clojure 1.3 and still work to this day (I did these examples in the latest 1.10.3 release) user=> (bigint "129110040087761027839616029934664535539337183380513") 129110040087761027839616029934664535539337183380513N user=> (type *1) clojure.lang.BigInt The Java-platform bigint is java.lang.BigInteger which are created with (biginteger) which was added in Clojure 1.0. Printing one of these will not include an N suffix: user=> (biginteger "129110040087761027839616029934664535539337183380513") 129110040087761027839616029934664535539337183380513 user=> (type *1) java.math.BigInteger Clojure BigInts are supposed to involve less unboxing and therefore be more performant. If you provide an integer literal that's too large to fit in a java.lang.Long, the reader will use a BigInt instead: user=> 129110040087761027839616029934664535539337183380513 129110040087761027839616029934664535539337183380513N user=> (type *1) clojure.lang.BigInt user=> 12345 12345 user=> (type *1) java.lang.Long If all this seems like a mess, well it sort of is. Clojure has a very strong commitment to backwards compatibility, so when the Clojure-specific big int representation was added, the old JDK-based one was not removed, because the operations that the two support are different.

jffry 5y ago

Yeah if you know you're definitely dealing with integers that are large, and are willing to pay the cost to promote into biginteger territory, that's certainly a way to do it with the stdlib. The nice ergonomic thing about clojure.math.numeric-tower is you can shove any of the Clojure numeric types at it (longs, doubles, but also Ratio or BigNum etc) and it'll intelligently handle the various combinations of types in order to give you the best answer it can