Folks,
I have been working on an R project that has a few dozen functions.
I have some questions that are only tangentially related and might only be a difference in style.
1. Some of my functions take single-row data.frames as input parameters lists. I don't force the user of the function to provide all of the parameters. I use code within a function to test if a particular parameter (column-name) exists in the data.frame and if so use the value of that parameter in a test. If the parameter doesn't exist in the data.frame then some default behavior applies like so:
if("rollDown" %in% names(runParams)) rollDown<-runParams[["rollDown"]]
else rollDown<-0
Is this good style? What are the pitfalls? Is there a better way?
One nice thing about this method is that if I need to add a new parameter I don't have to change the signature of the function.
2. What is a good way to organize a project with dozens of functions in R?
3. My project involves a fair amount of simulation. I am not talking hours but some of my "runs" take up to 30 minutes.
Suppose I have a "control" function that calls a number of other functions that might benefit from compilation (using the compiler package). Is it better to compile the called functions inside or outside the control function?
Is there a good "idiom" or standardized way of turning compilation of the called functions on and off? What about debugging (I use the debug package)?
I am perfectly happy with pointers to articles, books and code.
Thanks much for your time,
KW
--
Some unrelated questions.
5 messages · Keith S Weintraub, Bert Gunter, Jim Lemon +1 more
1. I would not presume to "advise" on good style. However, I will note that for your question (1) , default arguments and the "..." argument appears to be more standard. e.g. the function should be written as: myfunc(a1, a2, a3= something1, a4 = something2, ...) where arguments a1 and a2 are required, a3 and a4 are optional with defaults provided, and ... are miscellaneous other arguments that will be passed down to functions called by myfunc that uses them. However, this all begs the question: Have you read the R Language Definition manual?? These sorts of things are discussed there at length, and you **should read it** before posting here. Why? -- discussions there are reliable, written by certified experts; here you get advice from folks like me, who may or may not know what they're talking about! Cheers, Bert
On Mon, May 6, 2013 at 9:14 AM, Keith S Weintraub <kw1958 at gmail.com> wrote:
Folks,
I have been working on an R project that has a few dozen functions.
I have some questions that are only tangentially related and might only be a difference in style.
1. Some of my functions take single-row data.frames as input parameters lists. I don't force the user of the function to provide all of the parameters. I use code within a function to test if a particular parameter (column-name) exists in the data.frame and if so use the value of that parameter in a test. If the parameter doesn't exist in the data.frame then some default behavior applies like so:
if("rollDown" %in% names(runParams)) rollDown<-runParams[["rollDown"]]
else rollDown<-0
Is this good style? What are the pitfalls? Is there a better way?
One nice thing about this method is that if I need to add a new parameter I don't have to change the signature of the function.
2. What is a good way to organize a project with dozens of functions in R?
3. My project involves a fair amount of simulation. I am not talking hours but some of my "runs" take up to 30 minutes.
Suppose I have a "control" function that calls a number of other functions that might benefit from compilation (using the compiler package). Is it better to compile the called functions inside or outside the control function?
Is there a good "idiom" or standardized way of turning compilation of the called functions on and off? What about debugging (I use the debug package)?
I am perfectly happy with pointers to articles, books and code.
Thanks much for your time,
KW
--
______________________________________________ R-help at r-project.org mailing list 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.
Bert Gunter Genentech Nonclinical Biostatistics Internal Contact Info: Phone: 467-7374 Website: http://pharmadevelopment.roche.com/index/pdb/pdb-functional-groups/pdb-biostatistics/pdb-ncb-home.htm
see inline
On 05/07/2013 02:14 AM, Keith S Weintraub wrote:
Folks,
I have been working on an R project that has a few dozen functions.
I have some questions that are only tangentially related and might only be a difference in style.
1. Some of my functions take single-row data.frames as input parameters lists. I don't force the user of the function to provide all of the parameters. I use code within a function to test if a particular parameter (column-name) exists in the data.frame and if so use the value of that parameter in a test. If the parameter doesn't exist in the data.frame then some default behavior applies like so:
if("rollDown" %in% names(runParams)) rollDown<-runParams[["rollDown"]]
else rollDown<-0
Is this good style? What are the pitfalls? Is there a better way?
Whether it is good style or not, you must have been reading my mind. This is more or less what I am working on to streamline the increasing number of arguments in functions in some of the packages I maintain. At the moment I am trying to work out whether it is easier to have one big function to complete all the arguments or a set of smaller functions for related groups of arguments.
One nice thing about this method is that if I need to add a new parameter I don't have to change the signature of the function. 2. What is a good way to organize a project with dozens of functions in R?
Creating a package is an easy and well documented way of 1) keeping all the functions together 2) checking that everything works 3) maintaining a record of the evolution of the project Even a handful of functions can benefit from packaging.
3. My project involves a fair amount of simulation. I am not talking hours but some of my "runs" take up to 30 minutes. Suppose I have a "control" function that calls a number of other functions that might benefit from compilation (using the compiler package). Is it better to compile the called functions inside or outside the control function? Is there a good "idiom" or standardized way of turning compilation of the called functions on and off? What about debugging (I use the debug package)? I am perfectly happy with pointers to articles, books and code.
Jim
Jim, Thanks for your comments. KW --
On May 6, 2013, at 5:48 PM, Jim Lemon <jim at bitwrit.com.au> wrote:
see inline On 05/07/2013 02:14 AM, Keith S Weintraub wrote:
Folks,
I have been working on an R project that has a few dozen functions.
I have some questions that are only tangentially related and might only be a difference in style.
1. Some of my functions take single-row data.frames as input parameters lists. I don't force the user of the function to provide all of the parameters. I use code within a function to test if a particular parameter (column-name) exists in the data.frame and if so use the value of that parameter in a test. If the parameter doesn't exist in the data.frame then some default behavior applies like so:
if("rollDown" %in% names(runParams)) rollDown<-runParams[["rollDown"]]
else rollDown<-0
Is this good style? What are the pitfalls? Is there a better way?
Whether it is good style or not, you must have been reading my mind. This is more or less what I am working on to streamline the increasing number of arguments in functions in some of the packages I maintain. At the moment I am trying to work out whether it is easier to have one big function to complete all the arguments or a set of smaller functions for related groups of arguments.
One nice thing about this method is that if I need to add a new parameter I don't have to change the signature of the function. 2. What is a good way to organize a project with dozens of functions in R?
Creating a package is an easy and well documented way of 1) keeping all the functions together 2) checking that everything works 3) maintaining a record of the evolution of the project Even a handful of functions can benefit from packaging.
3. My project involves a fair amount of simulation. I am not talking hours but some of my "runs" take up to 30 minutes. Suppose I have a "control" function that calls a number of other functions that might benefit from compilation (using the compiler package). Is it better to compile the called functions inside or outside the control function? Is there a good "idiom" or standardized way of turning compilation of the called functions on and off? What about debugging (I use the debug package)? I am perfectly happy with pointers to articles, books and code.
Jim
R gives you facilities for doing this (using '...' and 'missing') without passing in a data.frame. For example,
foo <- function(arg1,arg2,...) { if (missing(arg1)) cat('missing arg1\n'); print(list(...)) }
foo(1,2,arg3=3,arg4=4,arg5=5)
$arg3 [1] 3 $arg4 [1] 4 $arg5 [1] 5
foo(arg2=2,arg3=3,arg4=4,arg5=5)
missing arg1 $arg3 [1] 3 $arg4 [1] 4 $arg5 [1] 5
Sent from my iPhone
On May 7, 2013, at 4:29 PM, Keith S Weintraub <kw1958 at gmail.com> wrote:
Jim, Thanks for your comments. KW --
On May 6, 2013, at 5:48 PM, Jim Lemon <jim at bitwrit.com.au> wrote:
see inline On 05/07/2013 02:14 AM, Keith S Weintraub wrote:
Folks,
I have been working on an R project that has a few dozen functions.
I have some questions that are only tangentially related and might only be a difference in style.
1. Some of my functions take single-row data.frames as input parameters lists. I don't force the user of the function to provide all of the parameters. I use code within a function to test if a particular parameter (column-name) exists in the data.frame and if so use the value of that parameter in a test. If the parameter doesn't exist in the data.frame then some default behavior applies like so:
if("rollDown" %in% names(runParams)) rollDown<-runParams[["rollDown"]]
else rollDown<-0
Is this good style? What are the pitfalls? Is there a better way?
Whether it is good style or not, you must have been reading my mind. This is more or less what I am working on to streamline the increasing number of arguments in functions in some of the packages I maintain. At the moment I am trying to work out whether it is easier to have one big function to complete all the arguments or a set of smaller functions for related groups of arguments.
One nice thing about this method is that if I need to add a new parameter I don't have to change the signature of the function. 2. What is a good way to organize a project with dozens of functions in R?
Creating a package is an easy and well documented way of 1) keeping all the functions together 2) checking that everything works 3) maintaining a record of the evolution of the project Even a handful of functions can benefit from packaging.
3. My project involves a fair amount of simulation. I am not talking hours but some of my "runs" take up to 30 minutes. Suppose I have a "control" function that calls a number of other functions that might benefit from compilation (using the compiler package). Is it better to compile the called functions inside or outside the control function? Is there a good "idiom" or standardized way of turning compilation of the called functions on and off? What about debugging (I use the debug package)? I am perfectly happy with pointers to articles, books and code.
Jim
______________________________________________ R-help at r-project.org mailing list 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.