Greg - I appreciate your taking the time to explain. This is very
helpful. My case was a bit unusual as I'm helping a colleague with code
to use on a regular but individual basis. I want them to name a data set
once at the top of the script and have that name propagate through
several objects that end up being saved at the end with file names tied
to the data set name. Then tomorrow, they'll do the same thing on a
different data set so each session would be pretty simple, with only 2-3
named objects at the end, though the data sets are big and cumbersome.
I'll dig into this more and apologize to those who thought this problem
was too trivial for the r-help forum.
David
On 6/24/2014 4:00 PM, Greg Snow wrote:
The main reason to avoid assign/get is that there are better ways.
You can use a list or environment more directly without using
assign/get. Also the main reason to use assign/get is to work with
global variables which are frowned on in general programming (and
prone to hard to find bugs).
Consider the following code snippet:
x <- 1:10
functionThatUsesAssign(x)
what is the value of x after running this code? If you use global
variables then the answer is "I don't know", and if x was something
that took several hours to compute and I just accidentally overwrote
it, then I am probably not happy.
Using assign often leads to the temptation to try code like:
assign( "x[5]", 25 )
which does something (no warnings, no errors) but generally not what
was being attempted.
Another common (mis)use of assign/get is to create a sequence of
variables like "data01", "data02", "data03", ... and then do the same
thing for each of the data objects. This is much better done by
putting all the objects into a single list, then you can easily
iterate over the list using lapply/sapply or still access the
individual pieces. Then when it comes time to save these objects, you
only need to save the list, not all the individual objects, same for
deleting, copying, moving, etc. And you don't have a bunch of
different objects cluttering your workspace, just a single list.
On Tue, Jun 24, 2014 at 2:57 PM, David Stevens <david.stev...@usu.edu> wrote:
Thanks to all for the replies. I tried all three and they work great. I was
misinterpreting the list = parameter in save(...) and I get your point about
overwriting existing objects. I've heard about not using assign/get before.
Can anyone point me to why and what alternatives there are?
Regards
David
On 6/24/2014 2:50 PM, Henrik Bengtsson wrote:
I recommend to use saveRDS()/readRDS() instead. More convenient and
avoids the risk that load() has of overwriting existing variables with
the same name.
/Henrik
On Tue, Jun 24, 2014 at 1:45 PM, Greg Snow <538...@gmail.com> wrote:
I think that you are looking for the `list` argument in `save`.
save( list=foo, file=paste0(foo, '.Rdata') )
In general it is best to avoid using the assign function (and get when
possible). Usually there are better alternatives.
On Tue, Jun 24, 2014 at 2:35 PM, David Stevens <david.stev...@usu.edu>
wrote:
R community,
Apologies if this has been answered. The concept I'm looking for is to
save() an object retrieved using get() for an object
that resulted from using assign. Something like
save(get(foo),file=paste(foo,'rData',sep=''))
where assign(foo,obj) creates an object named foo with the contents of
obj
assigned. For example, if
x <- data.frame(v1=c(1,2,3,4),v2=c('1','2','3','4'))
foo = 'my.x'
assign(foo,x)
# (... then modify foo as needed)
save(get(foo),file=paste(foo,'.rData',sep=''))
# though this generates " in save(get(foo), file = paste(foo, ".rData",
sep
= "")) :
object ‘get(foo)’ not found", whereas
get(foo)
at the command prompt yields the contents of my.x
There's a concept I'm missing here. Can anyone help?
Regards
David Stevens
--
David K Stevens, P.E., Ph.D.
Professor and Head, Environmental Engineering
Civil and Environmental Engineering
Utah Water Research Laboratory
8200 Old Main Hill
Logan, UT 84322-8200
435 797 3229 - voice
435 797 1363 - fax
david.stev...@usu.edu
______________________________________________
R-help@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.
--
Gregory (Greg) L. Snow Ph.D.
538...@gmail.com
______________________________________________
R-help@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.
--
David K Stevens, P.E., Ph.D.
Professor and Head, Environmental Engineering
Civil and Environmental Engineering
Utah Water Research Laboratory
8200 Old Main Hill
Logan, UT 84322-8200
435 797 3229 - voice
435 797 1363 - fax
david.stev...@usu.edu
______________________________________________
R-help@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.
--
David K Stevens, P.E., Ph.D.
Professor and Head, Environmental Engineering
Civil and Environmental Engineering
Utah Water Research Laboratory
8200 Old Main Hill
Logan, UT 84322-8200
435 797 3229 - voice
435 797 1363 - fax
david.stev...@usu.edu
______________________________________________
R-help@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.
