Promotion to BigDecimal doesn't happen - clojure

I'm using Clojure 1.5.1. Here is my program:
(def bricks4
(memoize (fn [n]
(cond (> 0 n) 0
(= 0 n) 1
(= 1 n) 1
:else (+ (bricks4 (- n 1))
(bricks4 (- n 2))
(bricks4 (- n 3))
(bricks4 (- n 4)))))))
(bricks4 70) throws exception:
ArithmeticException integer overflow clojure.lang.Numbers.throwIntOverflow (Numbers.java:1388)
I'm confused, because I thought Clojure will automatically promote numbers from Integer to Long and then to BigDemical.
What should I do to fix this program?

Clojure hasn't auto-promoted to bigint since 1.2, which is like...three years ago? These days the default is for better performance, but you can get the auto-promoting behavior by using +' instead of +, *' instead of *, and so on.

Related

Decimal to Binary Clojure

I'm following this pseudo code to convert decimal to binary recursively.
findBinary(decimal)
if (decimal == 0)
binary = 0
else
binary = decimal % 2 + 10 * (findBinary(decimal / 2)
This is what I have tried:
(defn binary [n]
(loop [res 0]
(if (= n 0)
res
(recur (res (* (+ (mod n 2) 10) (binary (quot n 2)))) )
)
)
)
But I get this error :
ClassCastException java.lang.Long cannot be cast to clojure.lang.IFn user/binary (form-init9002795692676588773.clj:6)
Any ideas how to fix the code to complete the task?
I realize, that this is about the journey and not the result. But to
have it mentioned: Long/toString can give you a string from a number with a wide
variety of radixes.
(Long/toString 123 2)
; → "1111011"
Here's a slightly different approach which allows recur to be used:
(defn find-binary [d]
(loop [ decimal d
digits '() ]
(if (= decimal 0)
(Integer. (clojure.string/join (map str digits)))
(recur (quot decimal 2) (conj digits (mod decimal 2))))))
In the loop we build up a collection of binary digits, adding each new digit at the beginning of the list so that we end up with the digits in the desired order left-to-right in the list. When the terminating condition is reached we convert the collection-of-digits to a collection-of-strings, join the collection of strings together into single string, and convert the string back to an integer.
Your psuedo code can be expressed pretty directly in clojure:
(defn find-binary [decimal]
(if (= decimal 0)
0
(+ (mod decimal 2) (* 10 (find-binary (quot decimal 2))))))
Examples:
user=> (find-binary 1)
1
user=> (find-binary 2)
10
user=> (find-binary 25)
11001
user=> (find-binary 255)
11111111
The error in your version is here:
(recur (res (* (+ (mod n 2) 10) (binary (quot n 2))))
Specifically, the complaint is that you are trying to use res (which has the value 0) as a function.
To be honest, I'm not sure how to do this with loop-recur. When I try it complains about recur not being from the tail position. Perhaps another answer can enlighten us!
Using recur:
;; returns a binary number string of the given decimal number
(defn find-binary [decimal]
(loop [n decimal
res ""]
(if (= n 0)
res
(recur (quot n 2)
(str (mod n 2) res)))))
But without loop:
(defn find-binary [decimal & {:keys [acc] :or {acc ""}}]
(if (= decimal 0)
acc
(find-binary (quot decimal 2) :acc (str (mod decimal 2) acc))))
The original attempt was the following, but it can't go far in the size of decimal:
(defn find-binary [decimal]
(loop [n decimal ;; number to be binarized
res '() ;; collector list
pos 0] ;; position of binary number
(if (= n 0)
(reduce #'+ res) ;; sum up collector list
(recur (quot n 2)
(cons (* (int (Math/pow 10 pos))
(mod n 2))
res)
(+ 1 pos)))))
For large numbers use:

Getting Execution error (StackOverflowError) when evaluating a function on larger range of values

I'm learning Clojure and solving exercises from SICP book in the process. I get this error when evaluating (search-for-primes 1001 10000) but when called on smaller values (search-for-primes 101 1000) it works fine.
This seems to be a memory issue but I'm unable to zero in on the cause of it. Would love your help. Thank you. Below is the code.
(defn square [x]
(* x x))
(defn divides? [a b]
(= (rem b a) 0))
(defn find-divisor [n test-divisor]
(cond
(> (square test-divisor) n) n
(divides? test-divisor n) test-divisor
:else (find-divisor n (+ test-divisor 1))))
(defn smallest-divisor [n]
(find-divisor n 2))
;;return true if prime
(defn prime?
[n]
(= n (smallest-divisor n)))
;;return the first of the three consecutive prime numbers
(defn search-for-primes [low high]
(if (< low high)
(cond
(and (prime? low) (prime? (+ low 2)) (prime? (+ low 4))) low
:else (search-for-primes (+ low 2) high))))
You don't show the actual error you're getting, but I'll guess that it has something to do with the stack overflowing.
Unlike Scheme, Clojure does not support tail call elimination, so you probably need to look at loop/recur, see https://clojuredocs.org/clojure.core/loop for example.

my Modulo Inverse in clojure Seems to give wrong answer

Hi I am programming in clojure and though the problem of modulo inverse has nothing to do with language i am stuck at this code -
(defn EulerDiv [x p]
(let [ToMod (+ p 2)]
(loop [num 1 toPow (int p) numDouble x]
(if (= 0 toPow)
num
(let [numDouble2 (rem (* numDouble numDouble) ToMod)
halfToPow (int (/ toPow 2))]
(if (odd? toPow)
(recur (rem (* num numDouble) ToMod)
halfToPow
numDouble2)
(recur num halfToPow numDouble2))
))))
)
It seems to give me right answers for small Primes but when i am using it in a problem with Bigger primes i am getting answers other than result like :
(= 2 (mod (* 4 (EulerDiv 2 (- 3 2))) 3))
This prints true
(def ToMod (+ 10e8 7))
( = 1 (int (mod (* 2 (EulerDiv 2 (- ToMod 2))) ToMod)) )
This prints false.
Also there is rem and mod in clojure.
mod makes the output positive and hence i can not use it in between the calculations.
It is a programming contest but this is just part of solution and this info of modulo inverse was also provided in the problem page.
The problem is that of programming calculator grammar for evaluating evpressions like 4/-2/(2 + 8)
You are straying from integer arithmetic.
Given integers, the / function can produce rationals: (/ 1 2) is 1/2, not 0.
And 1e9 is 1.0E9, a double, not an integer.
There are appropriate substitutes available. Look at the arithmetic section here for an integer division function, and at the cast section for something to convert a number to an integer.
All the best!

Overflow in Clojure computation despite using BigInt

The following closure computation overflows despite the use of big integers:
(defn binomial-coefficient [n k]
(let [rprod (fn [a b] (reduce * (range a (inc b))))]
(/ (rprod (- n k -1) n) (rprod 1 k))))
(binomial-coefficient 100N 50N)
I could not figure out where the overflow happens. For example, executing rprod by itself seems to work.
NB: the binomial coefficient code was taken from Rosetta Code.
The problem is that you're calling (rprod 1 k) with an integer 1 and not a bigint 1N:
(defn binomial-coefficient [n k]
(let [rprod (fn [a b] (reduce * (range a (inc b))))]
(/ (rprod (- n k -1) n) (rprod 1N k))))
(binomial-coefficient 100N 50N)
The problem lays in range function:
=> (range 1 10N)
(1 2 3 4 5 6 7 8 9)
=> (range 1N 10)
(1N 2N 3N 4N 5N 6N 7N 8N 9N)
Alternative solution is to use *', -' and inc' instead of ordinary *, - and inc operators, because they have build-in support for arbitrary precision and never overflow:
(defn binomial-coefficient [n k]
(let [rprod (fn [a b] (reduce *' (range a (inc' b))))]
(/ (rprod (-' n k -1) n) (rprod 1 k))))
(binomial-coefficient 100 50)

find all ordered triples of distinct positive integers i, j, and k less than or equal to a given integer n that sum to a given integer s

this is the exercise 2.41 in SICP
I have wrote this naive version myself:
(defn sum-three [n s]
(for [i (range n)
j (range n)
k (range n)
:when (and (= s (+ i j k))
(< 1 k j i n))]
[i j k]))
The question is: is this considered idiomatic in clojure? And how can I optimize this piece of code? since it takes forever to compute(sum-three 500 500)
Also, how can I have this function take an extra argument to specify number of integer to compute the sum? So instead of sum of three, It should handle more general case like sum of two, sum of four or sum of five etc.
I suppose this cannot be achieved by using for loop? not sure how to add i j k binding dynamically.
(Update: The fully optimized version is sum-c-opt at the bottom.)
I'd say it is idiomatic, if not the fastest way to do it while staying idiomatic. Well, perhaps using == in place of = when the inputs are known to be numbers would be more idiomatic (NB. these are not entirely equivalent on numbers; it doesn't matter here though.)
As a first optimization pass, you could start the ranges higher up and replace = with the number-specific ==:
(defn sum-three [n s]
(for [k (range n)
j (range (inc k) n)
i (range (inc j) n)
:when (== s (+ i j k))]
[i j k]))
(Changed ordering of the bindings since you want the smallest number last.)
As for making the number of integers a parameter, here's one approach:
(defn sum-c [c n s]
(letfn [(go [c n s b]
(if (zero? c)
[[]]
(for [i (range b n)
is (go (dec c) n (- s i) (inc i))
:when (== s (apply + i is))]
(conj is i))))]
(go c n s 0)))
;; from the REPL:
user=> (sum-c 3 6 10)
([5 4 1] [5 3 2])
user=> (sum-c 3 7 10)
([6 4 0] [6 3 1] [5 4 1] [5 3 2])
Update: Rather spoils the exercise to use it, but math.combinatorics provides a combinations function which is tailor-made to solve this problem:
(require '[clojure.math.combinatorics :as c])
(c/combinations (range 10) 3)
;=> all combinations of 3 distinct numbers less than 10;
; will be returned as lists, but in fact will also be distinct
; as sets, so no (0 1 2) / (2 1 0) "duplicates modulo ordering";
; it also so happens that the individual lists will maintain the
; relative ordering of elements from the input, although the docs
; don't guarantee this
filter the output appropriately.
A further update: Thinking through the way sum-c above works gives one a further optimization idea. The point of the inner go function inside sum-c was to produce a seq of tuples summing up to a certain target value (its initial target minus the value of i at the current iteration in the for comprehension); yet we still validate the sums of the tuples returned from the recursive calls to go as if we were unsure whether they actually do their job.
Instead, we can make sure that the tuples produced are the correct ones by construction:
(defn sum-c-opt [c n s]
(let [m (max 0 (- s (* (dec c) (dec n))))]
(if (>= m n)
()
(letfn [(go [c s t]
(if (zero? c)
(list t)
(mapcat #(go (dec c) (- s %) (conj t %))
(range (max (inc (peek t))
(- s (* (dec c) (dec n))))
(min n (inc s))))))]
(mapcat #(go (dec c) (- s %) (list %)) (range m n))))))
This version returns the tuples as lists so as to preserve the expected ordering of results while maintaining code structure which is natural given this approach. You can convert them to vectors with a map vec pass.
For small values of the arguments, this will actually be slower than sum-c, but for larger values, it is much faster:
user> (time (last (sum-c-opt 3 500 500)))
"Elapsed time: 88.110716 msecs"
(168 167 165)
user> (time (last (sum-c 3 500 500)))
"Elapsed time: 13792.312323 msecs"
[168 167 165]
And just for added assurance that it does the same thing (beyond inductively proving correctness in both cases):
; NB. this illustrates Clojure's notion of equality as applied
; to vectors and lists
user> (= (sum-c 3 100 100) (sum-c-opt 3 100 100))
true
user> (= (sum-c 4 50 50) (sum-c-opt 4 50 50))
true
for is a macro so it's hard to extend your nice idiomatic answer to cover the general case. Fortunately clojure.math.combinatorics provides the cartesian-product function that will produce all the combinations of the sets of numbers. Which reduces the problem to filter the combinations:
(ns hello.core
(:require [clojure.math.combinatorics :as combo]))
(defn sum-three [n s i]
(filter #(= s (reduce + %))
(apply combo/cartesian-product (repeat i (range 1 (inc n))))))
hello.core> (sum-three 7 10 3)
((1 2 7) (1 3 6) (1 4 5) (1 5 4) (1 6 3) (1 7 2) (2 1 7)
(2 2 6) (2 3 5) (2 4 4) (2 5 3) (2 6 2) (2 7 1) (3 1 6)
(3 2 5) (3 3 4) (3 4 3) (3 5 2) (3 6 1) (4 1 5) (4 2 4)
(4 3 3) (4 4 2) (4 5 1) (5 1 4) (5 2 3) (5 3 2) (5 4 1)
(6 1 3) (6 2 2) (6 3 1) (7 1 2) (7 2 1))
assuming that order matters in the answers that is
For making your existing code parameterized you can use reduce.This code shows a pattern that can be used where you want to paramterize the number of cases of a for macro usage.
Your code without using for macro (using only functions) would be:
(defn sum-three [n s]
(mapcat (fn [i]
(mapcat (fn [j]
(filter (fn [[i j k]]
(and (= s (+ i j k))
(< 1 k j i n)))
(map (fn [k] [i j k]) (range n))))
(range n)))
(range n)))
The pattern is visible, there is inner most map which is covered by outer mapcat and so on and you want to paramterize the nesting level, hence:
(defn sum-c [c n s]
((reduce (fn [s _]
(fn [& i] (mapcat #(apply s (concat i [%])) (range n))))
(fn [& i] (filter #(and (= s (apply + %))
(apply < 1 (reverse %)))
(map #(concat i [%]) (range n))))
(range (dec c)))))