On Tue, 2011-07-26 at 15:19 -0700, Davor Cubranic wrote:
> On 2011-07-23, at 5:57 AM, Alireza Mahani wrote:
>
> > Another trick to reduce verbosity of code (and focus on algorithm logic
> > rather than boilerplate code) is to maintain a global copy of variables (in
> > the global environment) whic
On 2011-07-23, at 5:57 AM, Alireza Mahani wrote:
> Another trick to reduce verbosity of code (and focus on algorithm logic
> rather than boilerplate code) is to maintain a global copy of variables (in
> the global environment) which makes them visible to all functions (where
> appropriate, of cour
Use tracemem() instead, i.e.
> A <- matrix(c(1.0,1.1), nrow=5, ncol=10);
> tracemem(A);
[1] "<0x047ab170"
> A[1,1] <- 7;
> B <- sqrt(A);
tracemem[0x047ab170 -> 0x0552f338]:
> A[1,1] <- 7;
> B <- t(A);
> A[1,1] <- 7;
tracemem[0x047ab170 -> 0x057ba588]:
> A[1,
Also consider subsetting:
cat("a: "); print(system.time( { A <- matrix(c(1.0,1.1),5,1000); 0 } ))
cat("h: "); print(system.time( { sum(A[1:5,1:1000]) } ))
cat("i: "); print(system.time( { sum(A[]) } ))
cat("j: "); print(system.time( { sum(A) } ))
In contrast with Python's NumPy array, the
Gabriel Becker writes:
AFAIK R does not automatically copy function arguments. R actually tries
very hard to avoid copying while maintaining "pass by value" functionality.
... R only copies data when you modify an object, not
when you simply pass it to a function.
This is a bit misleadin
The fact that R doesn't automatically copy the function argument is very
useful when you mainly want to pass arguments to another function. Thanks to
all of you for mentioning this!
Another trick to reduce verbosity of code (and focus on algorithm logic
rather than boilerplate code) is to maintain
> 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 elemen
> -Original Message-
> From: r-devel-boun...@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@r-project.org
> Subject: Re: [Rd] Best practices fo
On Fri, Jul 22, 2011 at 8:14 AM, Spencer Graves 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 i
On Jul 22, 2011, at 9: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 war
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 a
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
func
12 matches
Mail list logo
