(Since I'm currently between school symesters, I'm trying to get back into quest and progressing towards making a game)

In trying to avoid using recursion (as it piles up memory usage), and the issues with the 'while' Function's looping not waiting for its scripts to finish first, and thus the conflict with the 'get input ~ show menu', is the 'do~invoke' Scripts~Functions, an alternative?

How does the 'do~invoke' work in terms of memory usage? Are they Functions, and thus use recursion, being no different than all other Functions? Or, are they Method (Script Attribute) calls, which don't use recursion, and are like the looping programming, which doesn't use as much memory as recursion?

Otherwise, it seems that Pixie's roundabout method of using a second 'if' check is the only way to avoid recursive Functions? (or, are there any other alternative methods?)

------------------

off-topic (question on deeper understanding~knowledge in programming on memory and operation efficiencies):

I wasn't able to get around to asking my programming professors~teachers, on how~why looping (do, do-while, for, foreach, etc) works in not wasting up (at least as much) memory, as recursion does. Don't loops have to store~save~preserve data like recursive Functions, thus piling up memory in the stack?

Also, in terms of operation efficiency (more ambigious ~ situational question, I know), is recursion better or are loops better? How much extra operations are occuring in terms of looping vs recursion vs how many variables and other assignment~whatever etc operations you're doing, if it's possible to give a generalized repsonse~answer on this type of stuff, of course.

I will hopefully be learning more about all of this stuff in my continuing programming classes, but I'd like to get a bit of a head-start of a basic understanding in memory and operation efficiencies and their workings, so I can start to begin to program much better.

HK, I don't know the answer to the first part of your question but for your off-topic question, this may help:

http://stackoverflow.com/questions/3109 ... timization

The top answer explains it well.

If you don't have tail-call optimization in your language of choice or a similar solution recursion can be very inefficient.

HegemonKhan wrote:(Since I'm currently between school symesters, I'm trying to get back into quest and progressing towards making a game)

In trying to avoid using recursion (as it piles up memory usage), and the issues with the 'while' Function's looping not waiting for its scripts to finish first, and thus the conflict with the 'get input ~ show menu', is the 'do~invoke' Scripts~Functions, an alternative?

Do you have any evidence that you are running out of memory? How many layers of recursion do you anticipate?

I have helped Neonayon with the same thing and he (she?) has about twenty questions, and that seems to work fine as far as I can tell. A general solution is here:
viewtopic.php?f=18&t=5492

An alternative would be to use the "on ready" script command - as long as you are not using ShowMenu (it does not wait for ShowMenu).

How does the 'do~invoke' work in terms of memory usage? Are they Functions, and thus use recursion, being no different than all other Functions? Or, are they Method (Script Attribute) calls, which don't use recursion, and are like the looping programming, which doesn't use as much memory as recursion?

I guess "do" uses more memory than "invoke" as it also has "this" stored somewhere. Functions possibly use more as they have parameters (assuming you are not using delegates or dictionaries with the script). If you are having memory problems, try them and test it. Otherwise, I would not worry about it.

I wasn't able to get around to asking my programming professors~teachers, on how~why looping (do, do-while, for, foreach, etc) works in not wasting up (at least as much) memory, as recursion does. Don't loops have to store~save~preserve data like recursive Functions, thus piling up memory in the stack?

Each time you call a function it gets added to the stack (Quest has to know what called the function so it can jump back there after it terminates). Recursion is calling the function from itself, so each time you do that the stack will get bigger.

Loops also add to the stack, again Quest needs to know where the loop started. But that is a one off. If you loop a million times you still only get that one-off addition to the stack. Call a function recursively a million times and the stack will increase a million times.

The amount the stack increases each time should only be a few bytes (I guess), so even a hundred calls of your recursive function would only add about 1kb to the stack. I doubt that would impact on modern computers, with typically a few million kb of RAM (i.e. 1-8 Gb),

Also, in terms of operation efficiency (more ambigious ~ situational question, I know), is recursion better or are loops better? How much extra operations are occuring in terms of looping vs recursion vs how many variables and other assignment~whatever etc operations you're doing, if it's possible to give a generalized repsonse~answer on this type of stuff, of course.

Recursion gives you a shorter code, which is generally a good thing.

If you have a few thousand iterations you might possibly see a diference, but I doubt it. If you are asking a question at each step, it will take longer for the question to get sent to the player than for the code to run that step. There is no way the player will notice any difference, even playing off-line.

a BIG THANK YOU to George and Pixie! A ton of wealth of information.. albiet I really jumped into a can of worms... SOOOO MUUUUCH INFORMATION that I know nothing about in regards to programming, I've got a lot of stuff to try to learn, laughs...

(if only I could understand all of it easily, laughs. I'm still struggling with basic recursion and thus I'm struggling to make sense of "tail-recursion" and I'm not familiar with this 'Scheme' syntax, as I get what recursion is doing in it "drilling down" to the base case and then it has to "drill back up" to finish off each stack-layer of the called functions, but my brain just still has trouble with actually doing~using~applying~implementing it successfully, sighs)

I failed to solve how to do this on my Java final (had to use recursion to solve it):

    * 
   * * 
  * * * 
 * * * * 
  * * * 
   * * 
    * 

we had code to study for this:

 * * * * 
  * * * 
   * * 
    * 
   * * 
  * * * 
 * * * * 

but, that didn't help me at all, in solving the other pattern, sighs. My brain just isn't trained in recursion's "drilling down to base case and then drilling back up to each function call layer to finish each of them off".

-------------------------------------------------------------------------

@ Pixie:

--

Oh, this isn't about any specific issues in terms of memory or performance that have been issues with a game (I've not made any significant progress on a game of my own, lol), just asking about this stuff for in-general better code design, since now I'm at least aware of all of this stuff of programming, lol.

----

yes, I've been reading every post of~between neonayon and you, hehe. As she's making a RPG, as I'm interested in doing too, so her questions, are my questions, and your answers help me, as they do her. I've just not had the time to post due to school, but I've been lurking~reading both of your posts.

----

I actually was trying~testing to see if 'on ready' would work... I found out that you don't want to do:

while -> on ready -> get input

I haven't tried doing though:

while -> if ~ firsttime -> get input
while -> else ~ otherwise -> on ready -> get input

also, found out with the 'while', that it ends (totally nullifies the looping of) the while loop (as the while loop indeed doesn't wait for other actions at all ~ which makes it very hard to work with), via trying this:

flag = true -> while (flag) -> flag = false -> get input -> else (flag = true)

---

ah, so data gets piled up in the stack regardless of iteration~looping (do, do-while, for, foreach, etc) vs recursion, but since recursion (unless able to use 'tail-end' recursion) multiplies these layers of data due to having to "drill back up" (finishing off all of the layers of function calls), whereas iteration doesn't do this as its always only "one off" as you used.

---

hmm, how about in general with the programming languages, how do Method calls (Object.Method) work? do they use iteration or recursion?

further (fake and uber poor) psuedocode example:

(wow, I've already forgotten everything I know in C++, Java, and Python, laughs. I've only been done with finals for 3-4 days now!)

class Math {
  addition (a, b) {
    sum = a + b
    math.addition ( (sum + a), (sum+b) )
    // ignore its infinite looping issue
    msg (sum)
  }
}

There shouldn't be much difference between "do" and "invoke" in Quest, resources-wise. There is just the injection of the one extra "this" variable into a "do", which shouldn't take much. You can actually simulate a "do" with an "invoke" by passing a parameter dictionary and adding a "this" entry pointing to the desired object.

As far as Object.Method calls, they use neither iteration nor recursion. A single method call is neither. You get recursion if the function you call ends up calling back into itself (or somewhere in the chain) either directly or indirectly. And iteration and function/method calls are different things entirely. Iteration is a way to "loop back" within the same function. A method call invokes a completely separate bit of code, in a new, nested context. In your example, the first method call (to enter "addition") is neither recursion nor iteration. The call to "addition" within "addition" is a recursive call. Recursion is a higher-level concept based on *how* you make your function calls.

Regarding how much memory is taken for recursion, it all depends. In normal machine code, a subroutine call only pushes the return address, which will be something like 32- or 64 bits, depending on your machine architecture. Higher-level languages typically need more stack space per call, as certain registers typically need to be preserved. Also, each function call pushes whatever parameters you're passing and establishes a new call frame (a chunk of memory on the stack) to hold local variables. That's how each function call gets its own values for parameters and local variables. So if you had a C function with an automatic local 4K byte array, if you invoked it recursively, you'd eat at least 4K of stack space per call. Not good. Of course, that's not typical, and I don't how "managed" languages like Java handle stack. There must be some sort of storage from which to allocate local variables (a virtual stack?), so the concept would be similar in terms of memory usage and growth even if the actual processor stack isn't used.

Modern machines will typically grow the stack as needed. They all have hard limits though, either programmatically set or defined by the amount of available memory. You really don't want to push your memory usage into a paging situation, though, as the system will slow to a crawl, which will make your users very unhappy!

Keep in mind that a "get input"-calling-function situation (even calling itself) is not recursive, as the "get input" does not nest - it merely sets up the script as a completion callback when the input is done. It might look recursive, but it's not. Quest will invoke the script at a later time, but there is never more than one instance of the script running at a given time.

And it makes no sense to put "get input" inside a direct loop, as "get input" doesn't block. It just sets up the input "state", which it doesn't make sense to do repeatedly. As I'm sure you've discovered...

Thank you, Jay!, I'll be reading and trying to digest all of this (a bit beyond my learning as I've not done-learned any of the low level stuff yet), laughs! Any information on trying to understand programming better, I'm so very greatly appreciative of to all!

----

jay wrote:You really don't want to push your memory usage into a paging situation, though, as the system will slow to a crawl, which will make your users very unhappy!

Ya, I think in general, if I remember reading it right (when I was learning software, hardware, and networking about 2-3 years ago), you always want to leave at least a minimum of 15% of free-unused memory on your computer (out of your total memory).