So do you have preference? They are short examples but I felt the Subroutine ran a little faster than the Function..then again the function had to deal with strings
Thanks for the examples by the way. I am loosely defining Recursion as just multiple calls. So I've looking at this from the perspective of calling the same subroutine from the main program. You've some very good example of recursive calls within the Subroutine and Function. I have never really approached recursion within the routine but that recursion within the Function is what I have been thinking of doing.
Also would appear, in terms of speed.... I should be considering the time involved in multiple calls from the main program to the same subroutine v's recursive calls within a Function. (not exactly sure how to re-code the program to do this) But I'm thinking one call to the Function may in fact be faster.
The solution is to use Static variables.Don't know about that, my instinct would would be to Share the variable and give it a name not likely to be used elsewhere.
Wondering if I have this straight .. There is a danger with a Recursive procedure to cause a Stack Overflow. The solution is to use Static variables. I see where the recursive Quick Sort does not use Static variables (at least I have never declared Static variables when I use the Quick Sort method). So I'm thinking, if I create a Recursive procedure whereby a math formula is deployed (+,-,*,/) then this is were the danger lays. If the Recursion is simple comparisons, or True/False, or re-ordering then there is no threat to Overflow the Stack. Is that correct?I think it's worth explaining exactly what a stack overflow is and why it occurs:
@bplus and @luke ... Trapping I guess would be error code 256, which is too many gosub calls. So to monitor it I would think I need to count the number of calls to the routine and capture that number. If the routine does not error out I'm golden, but if it does then somehow I need to put a limit on the recursions being performed using that call count. In theory then, I should be able to identify the upper recursion limit of any of my recursive sub/function routines. Correct, or would the stack have other factors which would make the call count unreliable?
@SMcNeill ... is the variable "kolor" always = 0? If not how is the value for "kolor" assigned. I'm thinking, if the kolor value is being calculated multiple times somewhere in your code, then that multiple call is the recursive stack loading problem that I missed seeing.
Or does the subroutine itself would fall within the scope of "Recursive" because there are multiple "if" statements? I would think multiple 'if" statements would be quite a bit less of a stack load (ie the stack doesn't have to remember as many addresses).
I don't believe stack overflow can be effectively trapped (note the GoSub system is independent). On my system I just get a segmentation fault, Windows will probably have a similarly-fatal error.
It's also important to note that the stack size can differ between computers, so what works for you might not work elsewhere.
Still, let's assume a 1MB stack (not unreasonable). There's a bit of space taken at the start for bookkeeping and runtime stuff. A subroutine call takes 8 bytes for the return address, 8 bytes for bookkeeping and then space for local variables. If we have none, that's 16 bytes per stack frame which gives up a maximum call depth of about 65 thousand (actually 2^16). I haven't tested this, and I might have missed some extra local variables that are implicitly created by QB64, but hopefully it gives you an idea of the kind of scales to expect.
If you want the easiest example of recursion, then I'd like to add in a simple Fill routine for folks to study:Code: QB64: [Select]
Give it a center point. It then paints the pixels around it, if they're not already the proper color. Then it moves to those pixels and repeats the process. On and on, until the region to be painted is filled in completely.
Note, this should probably have a simple IF x < 0 or y < 0 or X >= _WIDTH or y >=_HEIGHT Then EXIT SUB in it just to make certain that it doesn't try to work itself to death off-screen on us. ;)
OK I checked back and I was not using recursion, whew!
How you folks convince Windows to toss you an error message is beyond me.I run the code posted above using QB64 x64 2.0.1, the code is already evident. The OS is Windows 8.1Pro on HP notebook 500HDD, 4 GB RAM, Celeron 2.00Ghz CPU N2810.
also Steve code compile fine
but when i run it ..then crush ...
i asking why ??Code: QB64: [Select]
i changed kolor var to _offset and then program started but then crush
In terms of the load on the stack: Lets say you have a program of a couple of thousand lines and in the main section there are multiple opening and closing files capturing tons of data and placing that in arrays. Then there are many many Do Loops with multiple If statements and Select Cases. Your program runs with no stack issues. Now suppose you can see where the lines of code can be reduced by eliminating the Do Loops with Recursive Subs or Functions. Would it be safe to conclude the effect of stack load is the same (ie there should be no issue)?
Code: QB64: [Select]
Screen _NewImage(640, 480, 32)
Circle (240, 240), 30, &HFFFF0000
Fill 240, 240, &HFFFF0000
Sub Fill (x, y, kolor As Long)
If Point(x, y) <> kolor Then Pset (x, y), kolor
If Point(x + 1, y) <> kolor Then Fill x + 1, y, kolor
If Point(x - 1, y) <> kolor Then Fill x - 1, y, kolor
If Point(x, y + 1) <> kolor Then Fill x, y + 1, kolor
If Point(x, y - 1) <> kolor Then Fill x, y - 1, kolor
End Sub
Would CLS clear the stack? If not, is there another command or routine which clears the stack. I would think the completion of the recursive sub or function clears the stack upon return to the main program for a fresh set of addresses but is that the only way the stack resets?
A recursive routine can act as a loopYes a loop in which you take track of previouse value and actions done in the recursive block!
@bplus @Dimster
what do you think about the FOR STEP NEXT glitch pointed out by my example?
@bplus - GCD has potential application in some of the data crunching I'm working with, thanks for same. The question I have on that routine is , How would it meet the definition of Recursion as we have been discussing here? I understand Recursion is a sub/function which calls itself but there does not appear to be a specific call to itself in the GCD code.
One other question @bplus - I notice you initialized the variables before each looping. Is there an advantage to this or just because there were multiple values in "a" prior to the looping? Especially when variable "a" which gets its values in the For statement so the prior values should be overwritten??
Waiting when I can observe array variable with variable index