[Rd] Best practices for writing R functions

[Paul Gilbert]

> -----Original Message-----
> From: r-devel-bounces at r-project.org [mailto:r-devel-bounces at r-
> project.org] On Behalf Of Gabriel Becker
> Sent: July 22, 2011 11:38 AM
> To: Spencer Graves
> Cc: Alireza Mahani; r-devel at r-project.org
> Subject: Re: [Rd] Best practices for writing R functions
> 
> On Fri, Jul 22, 2011 at 8:14 AM, Spencer Graves
> <spencer.graves at prodsyse.com
> > wrote:
> 
> >      From my personal experience and following this list some for a
> few
> > years, the best practice is initially to ignore the compute time
> question,
> > because the cost of your time getting it to do what you want is far
> greater,
> > at least initially.  Don't worry about compute time until it becomes
> an
> > issue.  When it does, the standard advice I've seen on this list is
> to
> > experiment with different ways of writing the same thing in R, guided
> by
> > "profiling R code", as described in the "Writing R Extensions"
> manual.
> >  (Googling for "profiling R code" identified examples.)
> >
> >
> >      Hope this helps.
> >      Spencer Graves
> >
> >
> >
> > On 7/22/2011 6:26 AM, Alireza Mahani wrote:
> >
> >> I am developing an R package for internal use, and eventually for
> public
> >> release. My understanding is that there is no easy way to avoid
> copying
> >> function arguments in R (i.e. we don't have the concept of pointers
> in R),
> >> which makes me wary of freely creating chains of function calls
> since each
> >> function call implies data copy overhead.
> >>
> >
> AFAIK R does not automatically copy function arguments. R actually
> tries
> very hard to avoid copying while maintaining "pass by value"
> functionality.

But beware that a function makes a copy of the argument as soon as you try to modify something in that argument. So, for example, if you have a big list object as an argument and are going to modify one element in the list, you will save memory by making a local copy of the single element and modifying that. However, as others have said, I would not worry until you find there is a problem. 

Paul

> Consider the following functions and their output:
> 
> 
> nomod = function(dat)
>   {
>     TRUE
>   }
> 
> mod = function(dat, i)
>   {
>     dat[5] = 5
>     TRUE
>   }
> 
> 
> > vec = rep(0, times = 10)
> > tracemem(vec)
> [1] "<0x8c85978>"
> > nomod(vec)
> [1] TRUE
> > mod(vec)
> tracemem[0x8c85978 -> 0x8c85c70]: mod
> [1] TRUE
> 
> So in the nomod function, the argument never actually gets copied (that
> is
> what tracemem tracks). R only copies data when you modify an object,
> not
> when you simply pass it to a function
> 
> HTH,
> ~G
> 
> 
> 
> >
> >> Is the above assessment fair? Are there any good write-ups on best
> >> practices
> >> for writing efficient R libraries that take into consideration the
> >> above-mentioned limitations, and any others that might exist?
> >>
> >> Thank you,
> >> Alireza
> >>
> >>
> >> --
> >> View this message in context: http://r.789695.n4.nabble.com/**
> >> Best-practices-for-writing-R-**functions-
> tp3686674p3686674.**html<http://r.789695.n4.nabble.com/Best-practices-
> for-writing-R-functions-tp3686674p3686674.html>
> >> Sent from the R devel mailing list archive at Nabble.com.
> >>
> >> ______________________________**________________
> >> R-devel at r-project.org mailing list
> >> https://stat.ethz.ch/mailman/**listinfo/r-
> devel<https://stat.ethz.ch/mailman/listinfo/r-devel>
> >>
> >>
> > ______________________________**________________
> > R-devel at r-project.org mailing list
> > https://stat.ethz.ch/mailman/**listinfo/r-
> devel<https://stat.ethz.ch/mailman/listinfo/r-devel>
> >
> 
> 
> 
> --
> Gabriel Becker
> Graduate Student
> Statistics Department
> University of California, Davis
> 
> 	[[alternative HTML version deleted]]
> 
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
====================================================================================

La version française suit le texte anglais.

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

This email may contain privileged and/or confidential information, and the Bank of
Canada does not waive any related rights. Any distribution, use, or copying of this
email or the information it contains by other than the intended recipient is
unauthorized. If you received this email in error please delete it immediately from
your system and notify the sender promptly by email that you have done so. 

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

Le présent courriel peut contenir de l'information privilégiée ou confidentielle.
La Banque du Canada ne renonce pas aux droits qui s'y rapportent. Toute diffusion,
utilisation ou copie de ce courriel ou des renseignements qu'il contient par une
personne autre que le ou les destinataires désignés est interdite. Si vous recevez
ce courriel par erreur, veuillez le supprimer immédiatement et envoyer sans délai à
l'expéditeur un message électronique pour l'aviser que vous avez éliminé de votre
ordinateur toute copie du courriel reçu.