How can certain variables be automatically excluded from being saved?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

How can certain variables be automatically excluded from being saved?

Ralf Goertz-2
Hi,

after having read here about the "seed problem" I wonder if there is a
way to automatically exclude certain variables from being saved when the
workspace image is saved at the end of an interactive session. I have
been using .First() and .Last() for ages but apparently they are of no
help as .First() gets called before loading the workspace and .Last()
after it has been saved. At least the line

if (".Random.seed" %in% ls(all.names=T)) rm(.Random.seed, pos=1)

in either of those functions doesn't have the desired effect.

______________________________________________
[hidden email] mailing list -- To UNSUBSCRIBE and more, see
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.
Reply | Threaded
Open this post in threaded view
|

Re: How can certain variables be automatically excluded from being saved?

Jim Lemon-4
Hi Ralph,
I suppose you could write a wrapper for q():

byebye<-function(drop=".Random.seed",save = "default", status = 0,
runLast = TRUE) {
 if(drop %in% ls(all.names=TRUE)) rm(drop,pos=1)
 q(save=save,status=status,runLast=runLast)
)

warning: untested

Jim

On Thu, Apr 1, 2021 at 7:05 PM Ralf Goertz <[hidden email]> wrote:

>
> Hi,
>
> after having read here about the "seed problem" I wonder if there is a
> way to automatically exclude certain variables from being saved when the
> workspace image is saved at the end of an interactive session. I have
> been using .First() and .Last() for ages but apparently they are of no
> help as .First() gets called before loading the workspace and .Last()
> after it has been saved. At least the line
>
> if (".Random.seed" %in% ls(all.names=T)) rm(.Random.seed, pos=1)
>
> in either of those functions doesn't have the desired effect.
>
> ______________________________________________
> [hidden email] mailing list -- To UNSUBSCRIBE and more, see
> 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.

______________________________________________
[hidden email] mailing list -- To UNSUBSCRIBE and more, see
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.
Reply | Threaded
Open this post in threaded view
|

Re: How can certain variables be automatically excluded from being saved?

Duncan Murdoch-2
In reply to this post by Ralf Goertz-2
On 01/04/2021 4:05 a.m., Ralf Goertz wrote:

> Hi,
>
> after having read here about the "seed problem" I wonder if there is a
> way to automatically exclude certain variables from being saved when the
> workspace image is saved at the end of an interactive session. I have
> been using .First() and .Last() for ages but apparently they are of no
> help as .First() gets called before loading the workspace and .Last()
> after it has been saved. At least the line
>
> if (".Random.seed" %in% ls(all.names=T)) rm(.Random.seed, pos=1)
>
> in either of those functions doesn't have the desired effect.

Jim suggested a way to do that, but I don't think it's really a good
idea:  it just fixes one aspect of the problem, it doesn't solve the
whole thing.

The real problem is saving the workspace occasionally, but always
loading it.  The "always loading" part is automatic, so I think the real
solution should address the "occasionally saving" part.

If you always save the workspace, things are fine.  You'll save the seed
at the end of one session, and load it at the beginning of the next.

If you never save the workspace, things are also fine.  You'll always
generate a new seed in each session that needs one.

Personally, I believe in the "never save it" workflow.  I think it has
lots of benefits besides the random seed issue:  you won't get a
more-and-more cluttered workspace over time, you end up with more
reproducible results, etc.  However, I can understand that some people
use a different workflow, so "always save it" is sometimes a reasonable
choice.

So the real problem is the "sometimes save it" workflow, which is
**encouraged** by the default q(save = "default") option, which asks
when interactive.  Changing the default to act like q(save = "no") would
be my preference (and that's how I configure things), but changing it to
act like q(save = "yes") would be an improvement over the current choice.

Duncan Murdoch

______________________________________________
[hidden email] mailing list -- To UNSUBSCRIBE and more, see
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.
Reply | Threaded
Open this post in threaded view
|

Re: How can certain variables be automatically excluded from being saved?

Ralf Goertz-2
Am Thu, 1 Apr 2021 08:39:45 -0400
schrieb Duncan Murdoch <[hidden email]>:

> On 01/04/2021 4:05 a.m., Ralf Goertz wrote:
> > Hi,
> >
> > after having read here about the "seed problem" I wonder if there
> > is a way to automatically exclude certain variables from being
> > saved when the workspace image is saved at the end of an
> > interactive session. I have been using .First() and .Last() for
> > ages but apparently they are of no help as .First() gets called
> > before loading the workspace and .Last() after it has been saved.
> > At least the line
> >
> > if (".Random.seed" %in% ls(all.names=T)) rm(.Random.seed, pos=1)
> >
> > in either of those functions doesn't have the desired effect.
>
> Jim suggested a way to do that, but I don't think it's really a good
> idea:  it just fixes one aspect of the problem, it doesn't solve the
> whole thing.
>
> The real problem is saving the workspace occasionally, but always
> loading it.  The "always loading" part is automatic, so I think the
> real solution should address the "occasionally saving" part.

Yes, that is exactly what I quite often do. I have to work in different
projects and I usually start R in the project directory. When I do
serious stuff I save afterwards. But quite often I want to check
something quickly and then I don't want to clutter up my workspace.

> If you always save the workspace, things are fine.  You'll save the
> seed at the end of one session, and load it at the beginning of the
> next.
>
> If you never save the workspace, things are also fine.  You'll always
> generate a new seed in each session that needs one.
>
> Personally, I believe in the "never save it" workflow.  I think it
> has lots of benefits besides the random seed issue:  you won't get a
> more-and-more cluttered workspace over time, you end up with more
> reproducible results, etc.  However, I can understand that some
> people use a different workflow, so "always save it" is sometimes a
> reasonable choice.
>
> So the real problem is the "sometimes save it" workflow, which is
> **encouraged** by the default q(save = "default") option, which asks
> when interactive.  Changing the default to act like q(save = "no")
> would be my preference (and that's how I configure things), but
> changing it to act like q(save = "yes") would be an improvement over
> the current choice.

I would prefer to be able to only save the history since that is where
the work is done. Usually, my data is easily restored using commands
from the history. I could probably accomplish that by linking .RData to
/dev/null or making it an empty readonly file. However, I would have to
do that in every directory I happen to use R in.

______________________________________________
[hidden email] mailing list -- To UNSUBSCRIBE and more, see
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.