I'm trying to get a function to work that divides two numbers, and returns their quotient.
I need to use recursive subtraction to find the quotient.
I don't really understand how to do this. I think I need a counter variable, which I increment by 1 each time I recurse the function. The problem is, I can only pass two arguments into this function:
(define (divide a b) so I'm not sure how to use the counter.
Can I get some psudeocode help?
Function result <- Divide ( a, b )
counter = 0
while a - b >= 0 do
a = a-b
counter = counter + 1
EndWhile
result = counter
End Function
Algoritm without_title
write "which numbers: "
read a b
result = Divide(a, b)
write "Result: ", result
EndAlgoritm
The counter is implicit in the recursion:
(define (divide n d)
(if (< n d)
0
(+ (divide (- n d) d) 1)))
Here n is the numerator and d is the denominator; we assume neither is negative. Here's an example:
> (divide 27 4)
6
This won't work if d is 0; do you see why?
Thinking recursively can be difficult when you first start. But if you keep plugging away at it, you will eventually learn to think recursively, and then you will wonder why you ever thought it was difficult.
Related
The goal is to create a code that will compute the sum of all integers from a to b
and if a > b then it should evaluate to 0.
(define (sum-from-to a b)
(if (> a b)
0
(+ a (sum-from-to (- a 1) b))))
My problem is that when I run this, I run out of memory. What's wrong with my code?
The recursive step is incorrect. Assuming that a <= b the fix is as simple as this:
(define (sum-from-to a b)
(if (> a b)
0
(+ a (sum-from-to (+ a 1) b)))) ; add 1, don't subtract
Think about it, we want a to become closer to b at each step, until it jumps over it. If we decrease a, then it'll move away from b, the exact opposite of what we want. That's why your procedure runs out of memory, a never reached b.
Well, here's one answer a mathematician would give: the sum of all integers from a to b is half of the sum of integers from a to b plus the sum of all integers from b to a. And this is a + b + a + 1 + b - 1 + ... + b + a which is a + b + a + b + ... + a + b. And this in turn is (a + b) * (b - a + 1). So the final sum is (a + b) * (a - b + 1) / 2 therefore. So just write that in Lisp, with the additional condition specified that for b < a:
(define (sum-a-b a b)
(if (> a b)
0
(/ (* (+ a b) (+ (- b a) 1)) 2)))
Of course, what is probably being looked for is either a recursive or an iterative answer. Either of those is a terrible solution to the problem: the recursive answer is terrible in both time & space complexity while the iterative one is merely terrible in terms of time complexity.
People who teach Lisp should stop actively trying to teach people to program badly.
I want to get a smallest integral divisor of a given number n
let rec smallest_divisor : int -> int
=fun n -> let i = ref 2 if n mod !i = 0 then i else (i :!i+1; smallest_divisor(n))
What I mean above that code is first variable i is 2, and if (n mod i) is 0 then return i, else i+1 and repeat that function
I really have no idea how to get this
For very large number it might be better to try testing only prime numbers. Your approach can work, but be aware that it might not be suitable for big numbers.
Another note: while writing recursive functions you should pay attention to the base case.
This is a minimal example that can achieve what you described, but keep in mind that it is not the best way to go about it:
let smallest_divisor n =
let rec aux n i =
if i > (n / 2) then n (* base case, should use sqrt here *) else
if (n mod i == 0) then i else aux n (i + 1) in
aux n 2;;
(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.
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.