I am going throw the Clojure for Machine Learning book and I dont understand one part of one function.
(defn square-mat
"Creates a square matrix of size n x n whose
elements are all e. Accepts an option argument
for the matrix implementation"
[n e & {:keys [implementation]
:or {implementation :persistent-vector}}]
(let [repeater #(repeat n %)]
(matrix implementation (-> e repeater repeater))))
(defn id-mat
"Creates an identity matrix of n x n size"
[n]
(let [init (square-mat :clatrix n 0)
identity-f (fn [i j n]
(if (= i j) 1 n))]
(cl/map-indexed identity-f init)))
In this second function, I don't understand this part (if ( = i j) than 1 else n). Why else n? n is size
Look at the definition of clatrix/map-indexed. It takes a function of three arguments (the row index, the column index, and the element in that position), and a matrix.
In the inner function (fn [i j n] (if (= i j) 1 n), n is bound not to the number of the rows in the matrix, but to the value in the position (i, j) - which happens to be always zero because the init matrix was initialized with zeros.
Looks like the book is using a very confusing notation (since n is bound to the number of rows in the matrix in the outer function, it would be better to name the third argument of the inner function x or somehow else), but the function should still work.
Related
(define (fib n)
(fib-iter 1 0 n))
(define (fib-iter a b count)
(if (= count 0)
b
(fib-iter (+ a b) a (- count 1))))
Just having some fun with SICP.
I completely understand the idea of Fibonacci algorithm but this code made me stuck up.
What exactly the last line does in compare to imperative style thing(is this just a basic recursion or)?
The procedure is implementing the Fibonacci series as an iterative process. In this case, fib is the main procedure that calls fib-iter, which does the actual work by means of an iteration. Notice that count is used to control the number of iterations we want, whereas a and b are used to store the results of the Fibonacci series for n-1 and n-2 respectively. The line (fib-iter (+ a b) a (- count 1)) is advancing the iteration to the next values.
Please take the time to read about iterative vs. recursive processes in the book, also read about tail recursion - these are the concepts you need to grasp for really understanding what's happening in the example.
For comparison, let's see how the same procedures would look using a more conventional syntax (Python's):
def fib(n):
return fib_iter(1, 0, n)
def fib_iter(a, b, count):
while count != 0: # same as asking `(if (= count 0) ...)`
a, b = a + b, a # same as passing `(+ a b) a` to recursive call
count -= 1 # same as `(- count 1)`
return b # same as returning `b` at end of recursion
As you see, the fib_iter procedure is simply iterating over a range of values controlled by the count variable, assigning a and b to the next values in the series, up until a number of iterations is completed; at this point the result is in b and is returned.
Suppose that I want to compute k√n rounded to the nearest integer, where n and k are nonnegative integers. Using binary search, I can find an integer a such that
ak ≤ n < (a+1)k.
This means that either a or a+1 is the kth root of n rounded to the nearest integer. However, I'm not sure how to determine which one it is without doing some calculations that involve floating-point arithmetic.
Given the values of a, n, and k, is there a way to determine the kth root of n rounded to the nearest integer without doing any floating-point calculations?
Thanks!
2kak < 2kn < (2a+1)k → (dividing by 2k) ak < n < (a+0.5)k → (taking the kth root) a < k√n < a+0.5, so the kth root of n is closer to a than to a+1. Note that the edge case will not occur; the kth root of an integer can not be an integer plus 0.5 (a+0.5) as the kth roots of n which are not kth powers are irrational and if n were a perfect kth power, then the kth root would be an integer.
The answers by Ramchandra Apte and Lazarus both contain what seems to be the essence of the correct answer, but both are also (at least to me) a bit hard to follow. Let me try to explain the trick they seem to be getting at, as I understand it, a bit more clearly:
The basic idea is that, to find out whether a or a+1 is closer to k√n, we need to test whether k√n < a+½.
To get rid of the ½, we can simply multiply both sides of this inequality by 2, giving 2·k√n < 2a+1, and by raising both sides to the k-th power (and assuming they're both positive) we get the equivalent inequality 2k·n < (2a+1)k. So, at least as long as 2k·n = n ≪ k does not overflow, we can simply compare it with (2a+1)k to obtain the answer.
In fact, we could simply compute b = ⌊ k√(2k·n) ⌋ to begin with. If b is even, then the closest integer to k√n is b / 2; if b is odd, it is (b + 1) / 2. Indeed, we can combine the two cases and say that the closest integer to k√n is ⌊ (b+1) / 2 ⌋, or, in pseudo-C:
int round_root( int k, int n ) {
int b = floor_root( k, n << k );
return (b + 1) / 2;
}
Ps. An alternative approach could be to compute an approximation (a+½)k directly using the binomial theorem as
(a+½)k
= ∑i=0..k (k choose i) ak−i / 2i
≈ ak
+ k·ak−1 / 2 + ... and compare it directly with n. However, at least naïvely, summing all the terms of the binomial expansion would still require keeping track of k extra bits of precision (or at least k−1; I believe the last term can be safely neglected), so it may not gain much over the method suggested above.
My guess is that you want to use this algorithm on an FPGA/CPLD, or a processor with limited resources, since your approach reminds me of CORDIC. Hence, I will give a solution with that in mind.
When you reach a^k ≤ n < (a+1)^k, it means that floor of x=root(n,k) is 'a'. In other words, x = a + f, where 0=<f<0.5. Thus, multiplying the equation by 2, you will have 2x=2a+2f. It basically means that floor(2x) = 2a (since 2f<1). Now, x = √n (kth root), thus 2x = k√((2^k)*n) (kth root). So, just shift n by k bits to left, then calculate its kth root with your algorithm. If its lower bound was exactly 2 times kth root of n, then kth root of n is a, otherwise it is a+1.
Assuming you have a function that gives you the lower bound of the kth root of n (rootk(n)), the final result, using binary operators and with C notations, would be:
closestint = a + ((rootk(n) << 1) == rootk(n>>k) );
Compute the cube of (a + 0.5)*10 (or 10a + 5 - no floating point arithmetic), then divide it by 1000.
Then check on which side the number is.
The idea of multiplying by 10 is to shift the decimal place one position to the right. Then we divide by 1000 because we multiplied by 10 3 times because of the cubing.
For example:
Input: 16
a = 2
a+1 = 3
a^3 = 8
(a+1)^3 = 27
10a + 5 = 25
25^3 = 15625
floor(15625 / 1000) = 15
16 > 15, thus 3 is closer.
It would also work to, as Oli pointed out, compute the cube of (a + 0.5)*2 (or 2a + 1), then divide it by 8.
For example:
2a + 1 = 5
5^3 = 125
floor(125 / 8) = 15
16 > 15, thus 3 is closer.
You can use Newton's method to find a; it works perfectly well with integers, and is faster than binary search. Then compute ak and (a+1)k using the square-and-multiply powering algorithm. Here's some code, in Scheme because I happened to have that handy:
(define (iroot k n) ; largest integer x such that x ^ k <= n
(let ((k-1 (- k 1)))
(let loop ((u n) (s (+ n 1)))
(if (<= s u) s
(loop (quotient (+ (* k-1 u) (quotient n (expt u k-1))) k) u)))))
(define (ipow b e) ; b^e
(if (= e 0) 1
(let loop ((s b) (i e) (a 1)) ; a * s^i = b^e
(let ((a (if (odd? i) (* a s) a)) (i (quotient i 2)))
(if (zero? i) a (loop (* s s) i a))))))
To determine which of ak and (a+1)k is closer to the root, you could use the powering algorithm to compute (a + 1/2)k — it's an exact calculation that the square-and-multiply operation can perform — then compare the result to n and determine which side is closer.
Edit: -
Sorry of misunderstanding the problem. Here is a possible solution of original question :-
Use newtons approximation theorem : -
here = means (approximately = )
f(b+a) = f(b) + a*f'(b)
a -> 0
f(x) = x^k
f'(x) = k*x^(k-1)
hence using above equation
f(a+0.5) = a^k + 1/2*k*a^(k-1);
need to check n < f(a+0.5)
n < a^k + 1/2*k*a^(k-1)
rearranging (n-a^k)*2 < k*a^(k-1)
Note: you can use binomial theorem to get more precision.
Think. Ideally, you'd do one more step of binary search, to see which side of a+½ the root lies. That is, test the inequality
(a+0.5)k < n
But the left hand side is difficult to compute precisely (floating point issues). So write down an equivalent inequality in which all the terms are integers:
(2a+1)k < 2k n
Done.
An iterative version of odd? for non-negative integer arguments can be written using and, or, and not. To do so, you have to take advantage of the fact that and and or are special forms that evaluate their arguments in order from left to right, exiting as soon as the value is determined. Write (boolean-odd? x) without using if or cond, but using and, or, not (boolean) instead. You may use + and -, but do not use quotient, remainder, /, etc.
A number is even if two divides it evenly, and odd if there if there is a remainder of one. In general, when you divide a number k by a number n, the remainder is one element of the set {0,1,…n-1}. You can generalize your question by asking whether, when k is divided by n, the remainder is in some privileged set of remainder values. Since this is almost certainly homework, I do not want to provide a direct answer to your question, but I'll answer this more general version, without sticking to the constraints of using only and and or.
(define (special-remainder? k n special-remainders)
(if (< k n)
(member k special-remainders)
(special-remainder? (- k n) special-remainders)))
This special-remainder? recursively divides k by n until a remainder less than n is found. Then n is tested for its specialness. In the case that you're considering, you'll be able to eliminate special-remainders, because you don't need (member k special-remainders). Since you only have one special remainder, you can just check whether k is that special remainder.
A positive odd number can be defined as 1 + 2n. Thus an odd number is:
If x is 1
If x is greater than 1 and x-2 is odd.
Thus one* solution that is tail recursive/iterative looks like this:
(define (odd? x)
(or (= ...) ; #t if 1
(and ... ; #f if less than 1
(odd? ...))); recurse with 2 less
*having played around with it it's many ways to do do this and still have it iterative and without if/cond.
The question i'm trying to answer:
The prime factors of 13195 are 5, 7, 13 and 29.
What is the largest prime factor of the number 600851475143 ?
Where am I going wrong? my prime? test seems to be the issue, but it works fine on relatively small numbers. However the prime? test gives a wrong answer with larger numbers. Is there an easier way to go about this?
(define b 3)
(define z 0)
(define divides?
(lambda (a b)
(= (remainder a b) 0)))
(define (prime? n)
(cond
((or (= n 1) (= n 0)) false)
((even? n) false)
((= n 2) true)
((= n b) true)
((divides? n b) false)
(else (and (set! b (+ b 1)) (prime? n)))))
;Largest Prime Factor Test
(define (LPF x)
(cond
((divides? 600851475143 x)
(cond
((prime? x)
(cond
((> x z) (set! z x)))))))
(if (< x 775146) (LPF (+ x 1)) (display z)))
Writing in a certain pseudocode, your intent seems to be
pe3 = last [x | x <- [2 .. 775146], isPrime x, rem 600851475143 x == 0]
read it: for x drawn from range 2 to 775146, if isPrime x holds, if 600851475143 % x is 0, collect such x; return the largest. We also write the application (g x) without the parentheses here, as just g x.
Calculating a remainder is cheaper than testing for primality, so we'll swap the two operations:
pe3 n = last [x | x <- [2 .. isqrt n], rem n x == 0, isPrime x]
This algorithm might work for the specific numbers involved, but unfortunately it is incorrect in general - say for 9000009, whose integer square root is 3000, it will return 101. But 9901 is the right answer (i.e. 9901 is the biggest prime divisor of 9000009, not 101).
Let's first focus on finding the smallest prime factor, instead:
pe3a n = head ([x | x <- [2 .. isqrt n], rem n x == 0, isPrime x] ++ [n])
Why the ( ... ++ [n]) (++ meaning the concatenation of lists)?? Because if n itself is prime, no divisor will be found at all, and the first list will come back empty, []. In which case the answer must be n itself. But if not, then the answer is the first (i.e. head) of the divisors list. Of course when we find it, we don't need to continue searching for more. Just one is enough, if the smallest is all we need.
OK, so trying it (at an imaginary lazy pseudocode interpreter), we get 3 as its first factor:
> pe3a 9000009
3
Now we can divide that 3 out of our number:
> div 9000009 3
3000003
and continue with 3000003, instead of 9000009. That means we can stop at its square root, 1732, instead of at 3000 - a sizable gain in efficiency! Also, we don't need to start over from 2 - it was tested already - we can start from the last found factor:
pe3b (start, n) = (d, div n d)
where
d = head ([x | x <- [start .. isqrt n], rem n x == 0, isPrime x] ++ [n])
> pe3b (3, 3000003)
(3,1000001)
so we get a second 3 back, and the number is divided by the found divisor once again.
> pe3b (3, 1000001)
(101,9901)
the next prime divisor found is 101, and the number to factorize now is 1000001 / 101 = 9901. Again we start from the last found divisor, 101, because all the smaller ones were already tried:
> pe3b (101, 9901)
(9901,1)
Interesting. isqrt(9901) == 99, the list [101 .. 99] is empty, and so the result was immediately produced. 9901 is the first factor of itself above 100, and in fact above 1, because all the previous numbers were already tried, in succession, and divided out of it. That means 9901 is a prime, no need to test it for primality.
In fact, all factors found by this algorithm are guaranteed to be prime by construction by the same reasoning, and all the calls to isPrime were superfluous.
Do also take note that the biggest number for which the division (the remainder operation) was performed here, was 101 - not 3000. Not only our new algorithm is correct, it is also much more efficient!
Now you can code in Scheme this algorithm of repeated pe3b application and dividing by the last found factor. Stop when 1 is reached.
So, in the same pseudocode,
divStep (start, n) = (d, div n d)
where d = head ([x | x <- [start .. isqrt n], rem n x == 0] ++ [n])
pe3 n = fst . until ((== 1) . snd) divStep $ (2,n) -- (1st,2nd) in a tuple
factorizing n = takeWhile ((> 1) . fst) . drop 1 . iterate divStep $ (2,n)
factors n = map fst . factorizing $ n
isPrime n = factors n == [n]
Read . and $ as "of". until pred step start is a higher-order pattern of repeated applications of a function, until a predicate is fulfilled ( ((== 1) . snd) means that the second component of a result equals 1). It is usually coded in Scheme with named let.
To see the whole history of computation, iterate step start is another pattern which collects all the interim results (and the starting value, which we don't need, so we drop it). To see just the factors themselves, we take the first components of each result with map fst. A number is prime if it's the only divisor, greater than 1, of itself. Testing:
> pe3 9000009
9901
> factorizing 9000009
[(3,3000003),(3,1000001),(101,9901),(9901,1)]
> factors 9000009
[3,3,101,9901]
> pe3 600851475143
6857
> factorizing 600851475143
[(71,8462696833),(839,10086647),(1471,6857),(6857,1)] -- 1471 is the largest
> factors 600851475143 -- factor tried,
[71,839,1471,6857] -- *not* 775146 !!
> factors 600851475143999917 -- isqrt 600851475143999917 == 775146099
[41,37309,392798360393] -- isqrt 392798360393 == 626736
Easy answer:
$ factor 600851475143
600851475143: 71 839 1471 6857
More serious answer: Your prime? function is indeed broken; I'm not even certain what it's trying to do. (Also, your (= n 2) test is too late to be useful: the (even? n) test has trumped it.)
My suggestion: Implement the Sieve of Eratosthenes. Here's my implementation.
I have been trying to find a tight bound time complexity for this function with respect to just one of the arguments. I thought it was O(p^2) (or rather big theta) but I am not sure anymore.
(define (acc p n)
(define (iter p n result)
(if (< p 1)
result
(iter (/ p 2) (- n 1) (+ result n))))
(iter p n 1))
#sarahamedani, why would this be O(p^2)? It looks like O(log p) to me. The runtime should be insensitive to the value of n.
You are summing a series of numbers, counting down from n. The number of times iter will iterate depends on how many times p can be halved without becoming less than 1. In other words, the position of the leftmost '1' bit in p, minus one, is the number of times iter will iterate. That means the number of times iter runs is proportional to log p.
You might try to eyeball it, or go from it more systematically. Assuming we're doing this from scratch, we should try build a recurrence relation from the function definition.
We can assume, for the moment, a very simple machine model where arithmetic operations and variable lookups are constant time.
Let iter-cost be the name of the function that counts how many steps it takes to compute iter, and let it be a function of p, since iter's termination depends only on p. Then you should be able to write expressions for iter-cost(0). Can you do that for iter-cost(1), iter-cost(2), iter-cost(3), and iter-cost(4)?
More generally, given an p greater than zero, can you express iter-cost(p)? It will be in terms of constants and a recurrent call to iter-cost. If you can express it as a recurrence, then you're in a better position to express it in a closed form.