basic q re: parsing functions, declaration order

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

basic q re: parsing functions, declaration order

Gowder, Paul
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…
______________________________________________
[hidden email] mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.
Reply | Threaded
Open this post in threaded view
|

Re: basic q re: parsing functions, declaration order

Jeff Newmiller
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:<[hidden email]>        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" <[hidden email]> 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…
>______________________________________________
>[hidden email] mailing list -- To UNSUBSCRIBE and more, see
>https://stat.ethz.ch/mailman/listinfo/r-help
>PLEASE do read the posting guide
>http://www.R-project.org/posting-guide.html
>and provide commented, minimal, self-contained, reproducible code.

______________________________________________
[hidden email] mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.
Reply | Threaded
Open this post in threaded view
|

Re: basic q re: parsing functions, declaration order

Bert Gunter
1. You should read a suitable R tutorial before proceeding. Is it not
advisable to learn a language's syntax before attempting to program in
it? An Intro to R ships with R, but there are many others available on
the Web. Choose that which suits. You may also wish to look at the R
Language manual; specifically your questions *may* have to do with
"lazy evaluation" in function calls (one aspect of which is: a default
argument in a function call is not evaluated until needed and can be
given a value in the body of a function that can depend on other
function arguments).

2. As Jeff intimated, you can use not -yet -defined functions in a
function definition (line # is a meaningless concept in R, though I
get your meaning). But the issue is: what is used when the function is
called.  This is all about scope, which in its full details is rather
complicated. But as Jeff intimated, in your situation, not worrying
about it may work fine.

Cheers,

Bert Gunter
Genentech Nonclinical Biostatistics
(650) 467-7374

"Data is not information. Information is not knowledge. And knowledge
is certainly not wisdom."
Clifford Stoll




On Sat, Apr 18, 2015 at 12:40 PM, Jeff Newmiller
<[hidden email]> wrote:

> 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:<[hidden email]>        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" <[hidden email]> 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…
>>______________________________________________
>>[hidden email] mailing list -- To UNSUBSCRIBE and more, see
>>https://stat.ethz.ch/mailman/listinfo/r-help
>>PLEASE do read the posting guide
>>http://www.R-project.org/posting-guide.html
>>and provide commented, minimal, self-contained, reproducible code.
>
> ______________________________________________
> [hidden email] mailing list -- To UNSUBSCRIBE and more, see
> https://stat.ethz.ch/mailman/listinfo/r-help
> PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
> and provide commented, minimal, self-contained, reproducible code.

______________________________________________
[hidden email] mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.
Reply | Threaded
Open this post in threaded view
|

Re: basic q re: parsing functions, declaration order

J Robertson-Burns
In reply to this post by Gowder, Paul
On 18/04/2015 18:14, Gowder, Paul 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,

[...]

>    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

Unless your results are massive, this is not worth
worrying about.

> }
>

[...]

>  
>
> 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?

Yes.  Functions just need to be defined at the
time they are used.

>
> 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…

Correct.  Not a line of thinking that you are
likely to need to defend among this crowd.

An answer to the question that you didn't ask is:

http://www.burns-stat.com/documents/books/the-r-inferno/

That question is:  Where do I look when I discover
it isn't doing what I intend it to do?

Pat

> ______________________________________________
> [hidden email] mailing list -- To UNSUBSCRIBE and more, see
> https://stat.ethz.ch/mailman/listinfo/r-help
> PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
> and provide commented, minimal, self-contained, reproducible code.

______________________________________________
[hidden email] mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.