Why my function is looping until Prolog crashes - recursion

I can't seem to understand why my function is looping until Prolog crashes:
isTerminalRow(_,_,_,Count,10):-
Count > 4.
isTerminalRow(B,A,Index,Count,Move):-
checkValue(B,Index,A,V),
C2 is V + Count,
I2 is Index + 1,
Move1 is Move + 1,
isTerminalRow(B,A,I2,C2,Move1).
checkValue(B,Index,A,V):-
getE(Index,B,Value),
Value = A, V is 1
; V is 0.
getE(1,[H|_],H). % get nth element
getE(I,[_|T],L):-
I1 is I - 1,
getE(I1,T,L).
The call is
?- isTerminalRow([w,w,w,w,w,e,e,e,e,e],w,1,0,10).

From your is uses, Move and Count are ground when you call isTerminalRow. For your first clause to fire, when Count becomes larger than 4, Move must be 10.
If not, the first clause does not fire; it doesn't even get a chance to consider the value of Count, and the execution continues with the second clause, which just loops (if checkValue/4 doesn't fail, that is).
Your termination conditions are too specific. Chances are, they are never met.
update: from your comments, Move is already 10 in your query, and Count is 0, so the first clause fails. After that, Move is always greater than 10 because you increment it with Move1 is Move + 1, and there's no chance for Count > 4 to even be tested, ever.

Related

In SML - Why doesn't simple recursion always return 0 if first expression met?

In a simple recursion with first if expression true then 0. if steps in the recursion keeps going until that first expression is true, why isn't 0 always returned?
fun stepping (n : int, number : int) =
if number > n
then 0
else 1 + stepping (n, number + 1)
It seems like the function stepping should add one onto number until number > n and then always return 0. Instead, it returns the number of times you went through the recursion cycle until number becomes greater than n.
The above code tests good in SML and gave me what I wanted - the number of steps incrementing by 1 until input "number" is greater than the input "n". But manually walking through the recursion steps, it seems like the return should always be 0 when the incremented "number" > the input "n". What am I missing?
I think you're mistaking the result of the final call to stepping in the recursive chain (which will always be zero) as being the ultimate value returned by the expression, but that is not the case. It is actually part of a larger equation that makes up the overall returned value.
For example, if we look at how the expression gets built up as each recursive call is made when evaluating stepping(3, 1), you end up with...
result = stepping(3, 1)
result = 1 + stepping(3, 2)
result = 1 + 1 + stepping(3, 3)
result = 1 + 1 + 1 + stepping(3, 4)
result = 1 + 1 + 1 + 0
result = 3
Let's say that I'm going to give you some money this year, according to this scheme:
you get nothing on the first of January
on all other days, you get one dollar more than I would have given you the day before
How much would I have to pay you today, the 20th of February?
Fifty dollars or nothing at all?
If you follow the calendar backwards, you will eventually reach January 1st, where the payment is zero, so would you expect to get nothing?
To answer your immediate question: the function does always return 0 if the first condition is met – that is, if number > n.
However, if the first condition isn't met – number <= n – it does not return 0 but 1 + stepping (n, number + 1).
It works exactly like of you called a function with a different name; that function computes a value and then this function adds 1.
It's not like returning a value from inside a loop, such as (pseudocode)
while (true)
{
if number > n
return 0
else
number = number +1
}
which is perhaps what you're thinking about.

for and if cicle operations

Hi¡ I have a doubt and I hope someone can help me please, I have a dataframe in R and it makes a double cicle for and an if, the data frame has some values and then if the condition is True, it makes some operations, the problem is I can't understand neither the cicle and the operation the code makes under the condition.
I reply the code I have in a simpler one but the idea is the same. And if someone can explain me the whole operation please.
w<-c(2,5,4,3,5,6,8,2,4,6,8)
x<-c(2,5,6,7,1,1,4,9,8,8,2)
y<-c(2,5,6,3,2,4,5,6,7,3,5)
z<-c(2,5,4,5,6,3,2,5,6,4,6)
letras<-data.frame(w,x,y,z)
l=1
o=1
v=nrow(letras)
letras$op1<-c(1)
letras$op2<-c(0)
for (l in 1:v) {
for (o in 1:v) {
if(letras$x[o]==letras$y[l] & letras$z[l]==letras$z[o] & letras$w[l]){
letras$op1<-letras$op1+1
letras$op2<-letras$x*letras$y
}
}
}
The result is the following:
Thanks¡¡¡¡¡
This segment of code is storing values into vectors labeled w,x,y,z.
w<-c(2,5,4,3,5,6,8,2,4,6,8)
x<-c(2,5,6,7,1,1,4,9,8,8,2)
y<-c(2,5,6,3,2,4,5,6,7,3,5)
z<-c(2,5,4,5,6,3,2,5,6,4,6)
It then transforms the 4 vectors into a data frame
letras<-data.frame(w,x,y,z)
This bit of code isn't doing anything as far as I can tell.
l=1 #???
o=1 #???
This counts how many rows is in the letras data frame and stores to v, in this case 11 rows.
v=nrow(letras)
This creates new columns in letras dataframe with all ones in op1 and all zeros in op2
letras$op1<-c(1)
letras$op2<-c(0)
Here each for loop is acting as a counter, and will run the code beneath it iteratively from 1 to v (11), so 11 iterations. Each iteration the value of l will increase by 1. So first iteration l = 1, second l=2... etc.
for (l in 1:v) {
You then have a second counter, which is running within the first counter. So this will iterate over 1 to 11, exactly the same way as above. But the difference is, this counter will need to complete it's 1 to 11 cycle before the top level counter can move onto the next number. So o will effectively cycle from 1 to 11, for each 1 count of 1l. So with the two together, the inside for loop will count from 1 to 11, 11 times.
for (o in 1:v) {
You then have a logical statement which will run the code beneath if the column x and column y values are the same. Remember they will be calling different index values so it could be 1st x value vs the 2nd y value. There is an AND statement so it also needs the two z position values to be equal. and the last part letras$w[l] is always true in this particular example, so could possibly be removed.
if(letras$x[o]==letras$y[l] & letras$z[l]==letras$z[o] & letras$w[l]){
Lastly, is the bit that happens if the above statement is true.
op1 get's 1 added (remember this was starting from 1 anyway), and op2 multiplies x*y columns together. This multiplication is perhaps a little bit inefficient, because x and y do not change, so the answer will calculate the same result each time the the if statement evaluates TRUE.
letras$op1<-letras$op1+1
letras$op2<-letras$x*letras$y
}
}
}
Hope this helps.

Fibonacci Tree-Recursion in Structure and Interpretation of Computer Programs

In the classic text by Abelson/Sussman, Structure and Interpretation of Computer Programs, in Section 1.2.2 on tree recursion and the Fibonacci sequence, they show this image:
The tree-recursive process generated in computing for the 5th Fibonacci number
Then they write: "Notice that the entire computation of (fib 3) - almost half the work - is duplicated. In fact, it is not hard to show that the number of times the procedure will compute (fib 1) or (fib 0) (the number of leaves in the above tree, in general) is precisely Fib(n + 1)."
I understand that they're making a point about tree-recursion and how this classic case of the Fibonacci tree-recursion is inefficient because the recursive function calls itself twice:
The tree-recursive function for computing a Fibonacci number
My question is, why is it obvious (i.e. "not hard to show") that the number of leaves is equal to the next Fibonacci number in the sequence? I can see visually that it is the case, but I'm not seeing the connection as to why the number of leaves (the reduced down fib 1 and fib 0 calculations) should be an indicator for the next Fibonacci number (in this case 8, which is Fib 6, i.e. the 6th Fibonacci number, i.e. Fib n+1 where n is 5).
It is obvious how the Fibonacci sequence is computed - the sum of the previous two numbers in the sequence yields the current number, but why does the number of leaves precisely equal the next number in the sequence? What is the connection there (other than the obvious, that looking at it and adding up the 1 and 0 leaves does, in fact, yield a total count of 8 in this case, which is the next (6th) Fibonacci number, and so on)?
"Not hard to show" is harder than "obvious".
Use induction with two base cases.
Let's call the number of computations in Fib(x), Fib01(x).
Then,
Fib01(0) = 1 by definition, which is Fib(1)
Fib01(1) = 1 by definition, which is Fib(2)
Now assume that Fib01(k) = Fib(k+1) for k < n:
Fib01(n) = Fib01(n-1) + Fib01(n-2)
= Fib(n) + Fib(n-1)
= Fib(n+1) by definition
QED.
The number of n=1 clauses must be equal to fib(n), because that is the only place a non-zero number comes from, and if the sum of some number of 1s is equal to fib(n), there must be fib(n) of them.
Since fib(n+1) = fib(n) + fib(n-1), we just need to show that there are fib(n-1) leaves computing fib(0). It's less obvious to me how to show this, but perhaps it falls inductively out of the previous case?
Perhaps a simpler approach is to just do the whole thing inductively, then.
For our base cases:
N=0: there are fib(N+1)=fib(1)=1 leaves in the tree. Proof by inspection.
N=1: there are fib(N+1)=fib(2)=1 leaves in the tree. Proof by inspection.
Induction step: to compute fib(N) for an arbitrary N, we compute fib(N-1) once, and fib(N-2) once, and add their results. By induction, there are fib(N) leaves in the tree coming from our computation of fib(N-1), and fib(N-1) leaves in the tree coming from our computation of fib(N-2).
There are therefore fib(N) + fib(N-1) leaves in our overall tree, which is equal to fib(N+1). QED.
We can prove this by extrapolation.
The number of leaves for Fib(0) = 1.
The number of leaves for Fib(1) = 1.
Now, the expression Fib(2) is basically the sum of Fib(1) + Fib(0), i.e., Fib(2) = Fib(1) + Fib(0). So from the tree itself, you can see that the number of leaves for Fib(2) is equal to the sum of leaves in case of Fib(1) and Fib(0). Therefore, the number of leaves for Fib(2) is equal to 2.
Next, for Fib(3) the number of leaves will be sum of leaves for Fib(2) and Fib(1), i.e., 2 + 1 = 3
As you must have observed by now, this follows a pattern similar to Fibonacci series. Infact if we define the number of leaves for Fib(n) to be FibLeaves(n), then we can see that this series is Fib(n) shifted left by 1 space.
Fib(n) = 0, 1, 1, 2, 3, 5, 8, 13, 21, ..
FibLeaves(n) = 1, 1, 2, 3, 5, 8, 13, 21, ..
And thus, the number of leaves will be equal to Fib(n + 1)
Look at it this way:
It is true that we can generate a part of the fibonnaci sequence by picking any two consecutive terms from anywhere in the full fibonnaci sequence and following the rules of generating the next term
i.e Full fibonnaci sequence = 0,1,1,2,3,5,8,13,21....
So if I picked any two consecutive terms e.x 3 and 5, and followed the rules of generating the next term in the sequence, I would generate a part of the fibonnaci sequence
i.e Part of fibonnaci sequence = 3,5,8,13,21,34...
It is true that the number of leaves for a term is equal to the sum of the number of leaves of its two previous terms. This rule is the same as that for generating a term in the fibonnaci sequence
So lets try to get the number of leaves for the second term i.e number of leaves for zeroth term + number of leaves for first term
The number of leaves for the zeroth term and first term is 1
The number of leaves for the second term becomes 1 + 1 = 2
Now, 1,1 are consecutive terms from the full fibonacci sequence and the rule for getting the number of leaves is the same as the rule for getting a term in the fibonacci sequence
Nice question! It is immediately obvious (after a moment's thought), because the number of leaves in a binary tree node is the sum of respective numbers for its two branches, and, vacuously, 1 for leaves -- which is the definition of Fibonacci numbers ... with this specific shape of a tree.
Implicit in the above imprecise general statement is the proof by induction that
N(0) = 1
N(1) = 1
N(n+2) = N(n+1) + N(n)
which directly maps onto that statement, making it specific and concrete!

Recursion on staircase

I'm trying to understand the solution provided in a book to the following question:
"A child is running up a staircase with n steps and can hop either 1 step, 2 steps or 3 steps at a time. Implement a method to count how many possible ways the child can run up the stairs."
The book's solution is as follows, stemming from the fact that "the last move may be a single step hop from n - 1, a double step hop from step n - 2 or a triple step hop from step n - 3"
public static int countWaysDP(int n, int[] map) {
if (n < 0)
return 0;
else if (n == 0)
return 1;
else if (map[n] > -1)
return map[n];
else {
map[n] = countWaysDP(n - 1, map) + countWaysDP(n - 2, map) + countWaysDP(n - 3, map);
return map[n]; }
}
My confusion is:
Why should the program return 1 if the number of steps is zero? The way I think about it, if the number of steps is zero, then there are zero ways to traverse the staircase. Wouldn't a better solution be something like "if (n <= 0) return 0; else if (n == 1) return 1"?
I'm not sure I understand the rationale behind making this a static method? Google says that a static method is one that is called by the entire class, and not by an object of the class. So the book's intention seems to be something like:
.
class Staircase {
static int n;
public:
static int countWaysDP(int n, int[] map); }
instead of:
class Staircase {
int n;
public:
int countWaysDP(int n, int[] map); }
Why? What's the problem with there being multiple staircases instantiated by the class?
Thanks.
(Note: Book is Cracking the Coding Interview)
To answer your first question, it turns it is the beauty of mathematics: if there is 1 step for the staircase, there is 1 way to solve it. If there is 0 steps, there is also 1 way to solve it, which is to do nothing.
It is like, for an n-step staircase, for m times, you can either walk 1, 2, or 3 steps to finish it. So if n is 1, then m is 1, and there is 1 way. If n is 0, m is 0, and there is also 1 way -- the way of not taking any step at all.
If you write out all the ways for a 2-step staircase, it is [[1, 1], [2]], and for 1-step staircase, it is [[1]], and for 0-staircase, it is [[]], not []. The number of elements inside of the array [[]] is 1, not 0.
This will become the fibonacci series if the problem is that you can walk 1 step or 2 steps. Note that fib(0) = 1 and fib(1) = 1, and it corresponds to the same thing: when staircase is 1 step, there is 1 way to solve it. When there is 0 steps, there is 1 way to solve it, and it is by doing nothing. It turns out the number of ways to walk a 2-step staircase is fib(2) is 2 and it equals fib(1) + fib(0) = 1 + 1 = 2, and it wouldn't have worked if fib(0) were equal to 0.
Answer 2:
A Static method means the function doesn't need any information from the object.
The function just takes an input (in the parameters), processes it and returns something.
When you don't see any "this" in a function, you can set it as static.
Non-static methods usually read some properties (this-variables) and/or store values in some properties.
Answer 1:
I converted this to javascript, just to show what happens.
http://jsbin.com/linake/1/edit?html,js,output
I guess this is the point. Recursion often works opposite to what you could expect. It often returns values in the opposite order.
For 5 staircases:
First it returns n=1; then n=2, ... up to n=5;
n=5 has to wait until n=4 is ready, n=4 has to wait until n=3 is ready, ...
So here is your n=0 and n<0:
The first return of the function has n=1; that calls this
map[n] = countWaysDP(n - 1, map) + countWaysDP(n - 2, map) + countWaysDP(n - 3, map)
So that is
map[n] = countWaysDP(0, map) + countWaysDP(-1, map) + countWaysDP(-2, map)
There countWaysDP(0, map) returns 1; the other terms are meaningless, so they return 0. That's why there are these clauses for n==0 and n<0
notice, you can add
+ countWaysDP(n - 4, map)
if you want to see what happens when the child can also jump 4 cases
Also notice:
As I said in answer 2, you see this function doesn't require any object. It just processes data and returns something.
So, in your case, having this function in your class is useful because your functions are grouped (they 're not just loose functions scattered around your script), but making it static means the compiler doesn't have to carry around the memory of the object (especially the properties of the object).
I hope this makes sense. There are surely people that can give more accurate answers; I'm a bit out of my element answering this (I mostly do javascript).
To try and answer your first question, why it returns 1 instead of 0, say you're looking at a stair with 2 steps in total, the recursive call then becomes:
countWaysDP(2 - 1, map) + countWaysDP(2 - 2, map) + countWaysDP(2 - 3, map);
The second recursive call is the one where n becomes zero, that's when we have found a successful path, because from 2 steps, there's obviously a path of taking 2 steps. Now, if you write as you suggested:
n == 1: return 1
you would not accept taking two steps from the two stepped stair! What the statement means is that you only count the path if it ends with a single step!
You need to think about it has a tree with 3 possible options on each node.
If the size of the staircase is 4
we will have something like this:
(4)--1-->(3)--..(Choose a step and keep branching)...
|__2-->(2)--..(Until you get size of zero)............
|__3-->(1)--1-->(0) # <--Like this <--
At the end if you count all the leafs with size of zero you will get all the possible ways.
So you can think it like this, what if you take a step and then consider update the size of the stair like this size-step, where your steps can be (1,2,3)
Doing that you can code something like this:
choices = (1, 2, 3)
counter = 0
def test(size):
global counter
if size == 0:
counter += 1
for choice in choices:
if size - choice >= 0:
test(size - choice)
return counter

prolog recursive error (easy)

I'm new to prolog. I'm doing a recursive program the problem is that even though it prints the answer.. it doesn't stop after printing the answer and eventually gives "Out of local stack".
I've read it could be a left recursion issue but as I've already told you I'm new to prolog and I don't really understand what happens...
so.. here's code.
f(X, Y):-
Y is sqrt(1-((X-1)*(X-1))).
sum(SEGMENTS, 1, TOTAL):-
f(2/SEGMENTS*1,H1),
TOTAL is (2/SEGMENTS)*H1.
sum(SEGMENTS, NR, TOTAL):-
N1 is (NR-1),
sum(SEGMENTS, N1, S1),
f(2/SEGMENTS*NR,H1),
f(2/SEGMENTS*N1,H2),
TOTAL is S1 + (2/SEGMENTS)*((H1+H2)/2).
It's supposed to calculate a semicircle area with the trapezoid rule or something similar.
As I've already told you .. it does finishes but after getting to the base case sum(segments, 1, total) it calls the function with the second alternative... :S
Thanks guys!
Also: Here's what I get when I run it
?- sum(3000,3000,TOTAL).
TOTAL = 1.5707983753431007 ;
ERROR: Out of local stack
The problem is that backtracking will attempt the case of NR value of 1 on the second sum clause after the first clause has succeeded. This causes a long recursion process (since NR is being decremented continually for each recursive call, attempting to wrap around through all negative integer values, etc).
A simple way to resolve the problem is in your second sum clause. Since the intention is that it is for the case of NR > 1, put NR > 1 as your first statement:
sum(SEGMENTS, NR, TOTAL) :-
NR > 1,
N1 is (NR-1),
sum(SEGMENTS, N1, S1),
f(2/SEGMENTS*NR,H1),
f(2/SEGMENTS*N1,H2),
TOTAL is S1 + (2/SEGMENTS)*((H1+H2)/2).
Also note that the expression f(2/SEGMENTS*NR, H1) doesn't compute the expression 2/SEGMENTS*NR and pass it to f. It actually passes that expression symbolically. It just happens to work here because f includes it on the right hand side of an is/2 so it is evaluated as desired. If you trace it, you'll see what I mean.

Resources