basic q re: parsing functions, declaration order

You will eventually learn that scope in R is rather different than any of those other languages. However, if you don't think too hard about it, you should find it quite natural. So yes, you can call "forward" if you like to think of it that way.

However, your reference to a mess of functions does not portend well for leaving it running over the weekend successfully. I highly recommend testing your code on progressively larger amounts of data to test it out. Functional programs can be built systematically in R even if you are still getting the hang of it, but each function should have a clear goal and as few side effects as possible.
---------------------------------------------------------------------------
Jeff Newmiller                        The     .....       .....  Go Live...
DCN:<jdnewmil at dcn.davis.ca.us>        Basics: ##.#.       ##.#.  Live Go...
                                      Live:   OO#.. Dead: OO#..  Playing
Research Engineer (Solar/Batteries            O.O#.       #.O#.  with
/Software/Embedded Controllers)               .OO#.       .OO#.  rocks...1k
---------------------------------------------------------------------------
Sent from my phone. Please excuse my brevity.

On April 18, 2015 10:14:31 AM PDT, "Gowder, Paul" <paul-gowder at uiowa.edu> wrote:

Hi there,

So I?m doing some serious coding in R for the first time?writing a
strategic simulation to run for a few (or many) thousand iterations,*
and doing so in proper functional programming form, i.e., with a bunch
of wrapper functions calling other wrapper functions calling the stuff
that does the real work.  So, like:

simulate.strat <- function(runs) {
 results <- # blah blah blah
 for (i in 1:runs) {
 run.res <- c(i,outer.wrapper())
 rbind(results,run.res)
 }
write.table(results, file="simul_results.csv", row.names=TRUE,
col.names=TRUE, sep=",?)
# bonus question: there?s probably a vastly more efficient way to do
this final write, any suggestions welcomed
}

outer.wrapper <- function() {
 goods <- dist.goods()
 power <- dist.power()
# blah blah blah
one.run <- inner.wrapper(goods, power, subgroups.num, subgroups.dist,
trust, trust.errorvar)
 return(one.run)
}

dist.goods <- function() {
 elite.goods <- sample(1000:4000, 1)
# blah blah blah
 goods.dist <- c(elite.dist, mass.dist)
 return(goods.dist)
}

and so forth.

I?m just putting it all in one source file, which I plan to load using
source(), and then actual execution will be via console input >
simulate.strat(number of runs), leave town for the weekend, hopefully
come back to find a csv with a bunch of results.

But I?m not quite sure how the parser works with respect to defining
all these functions.  Do I have to define them from inside out like one
would in python?  (So, on the code above, that would mean defining,
say, dist.goods() and dist.power() first, then outer.wrapper(), then
simulate.strat().)  Or is there a way to prototype them like one would
in C?  Or--- and I really hope this is the answer so I don?t have
untangle the tangled web of functions I?m writing? is R smart
enough/lazy enough to accept that the function defined at line K can
call a function defined at line K+N and not stress about it?

thanks so much!  My google-fu is failing me on this one.

-Paul


* why on earth, you might ask, am I doing this in R, rather than C or
something?  Because I have a ton of computing resources and a huge
workload. CPU time is cheap and my time is expensive?