Re: [Rd] Best practices for writing R functions

From: Paul Gilbert <pgilbert_at_bank-banque-canada.ca>
Date: Fri, 22 Jul 2011 18:59:31 +0000

> -----Original Message-----
> From: r-devel-bounces@r-project.org [mailto:r-devel-bounces@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.



R-devel_at_r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel Received on Fri 22 Jul 2011 - 19:07:26 GMT

This quarter's messages: by month, or sorted: [ by date ] [ by thread ] [ by subject ] [ by author ]

All messages

Archive maintained by Robert King, hosted by the discipline of statistics at the University of Newcastle, Australia.
Archive generated by hypermail 2.2.0, at Sat 23 Jul 2011 - 07:40:12 GMT.

Mailing list information is available at https://stat.ethz.ch/mailman/listinfo/r-devel. Please read the posting guide before posting to the list.

list of date sections of archive