Recursion
BlitzPlus Forums/BlitzPlus Programming/Recursion
| ||
| If you haven't tried recursive calls, you might be interested in the following effort. Note that there is a function test#(), and within the function, a local variable test#. Since that is allowed, I use the local variable to track what I intend to return when I exit the function. See if you can figure out what is going on and why. Function test#(parm) test#=parm+1 If test<10 Then Print test(test) Return test End Function Print test(0) Print test WaitKey() End |
| ||
| Your functions works, it just looks funny. Every time you call test again, the new value gets pushed onto the stack: 1,2,3,45,6,7,8,9,10 then when print finally get control of it it pops the values off the stack, and presto" 10,9,8,... The last number your function pushed on the stack is 10 and it gets popped first, of course, that why you see a reverse order of the numbers you expected. This probably wouldn't be an issue if you didn't call test again with the value of the parameter, all dished to the print function, which can't print a value yet, because the function has to execute to return the value to be printed. And so on... When everything is done, print finally gets the values to be printed (popped from stack-> last being first etc) and executes, that why you see the "unexpected" reversing. If you change the code to this: Function test#(parm) test#=parm+1 If test<10 Then Print test test(test) endif Return test End Function you will probably get what you expected. This is NOT a BB bug, its a logic error on the programs behalf... Hope that helps... |
| ||
| I enjoy your inquisitive mind. Gremlins have taken over your machine and caused it to start counting backwards. Just kidding. =) Actually, it seems like a textbook example of recursion. You initially call the function Test with a parameter of 0. The meat of the function is essentially a statement that adds 1 to Parm. After that, it reaches a base case test. The test is whether Parm + 1 >= 10. If it not, then the function calls itself with Parm + 1 as the new parameter. A copy of the variable scope (parm, test#) gets placed on the (function call) stack, and the new iteration of Test#(parm) begins. This repeats until Parm + 1 = 10. At this point, there are 10 function calls on the stack to Test#(), each with different variable scopes. Finally, a Return statement is reached, and so "10.0" is finally returned as the evaluated part of the Print statement, and is indeed printed. It isn't until this (the 9th) call of Test that it actually reaches the "end function" statement for the first time. This continues, each function recursively popping off the stack, until you're left with the original call, which returns 1, and happily prints it. The final print is 0 (test#=0), because it is outside of the function scope. Note that the more you do this, the more memory is used to keep track of the function call stack. Large, hungry recursive functions have been known to bring systems to their knees, which is why most programmers prefer the iterative version of a function, rather than the recursive function, unless it is a particularly elegant solution. One of the reasons this works is because it relies on the local scope of the function. Try declaring Test# as a global and see what happens. =) |
   |