Hi Scott,
options(warn = 2) is a great idea. Thank you. My suggestion was not to
change the behavior of last.warning, just to write what the behavior is
very explicitly in the help page. But I guess this is just difference of
opinions.
Thanks for the suggestions,
Elad
On Sun, Dec 29, 2013 at 3:51 AM, Scott Kostyshak <skost...@princeton.edu>wrote:
> On Sat, Dec 28, 2013 at 11:19 PM, Elad Zippory <elad.zipp...@gmail.com>
> wrote:
> > Hi Scott,
> >
> > Thank you for your detailed response. (btw, the reason why I didn't link
> the
> > Stack Overflow question is because I deleted it after I sent the e-mail).
>
> Hi Elad,
>
> Please keep the conversation on the list unless there is a reason for
> it to be private, in which case please say so. This way everyone can
> participate (and more importantly can correct my errors).
>
> > The rationale behind my proposal was because I was surprised to learn
> that
> > rm(list=ls()) does not clear the warning list. The reason why I was
> > surprised is because it is not clear from the help page (if you are at a
> > level that requires you to read the help page of such a base function,
> the
> > warning that I quoted does not fully warn the 'user', who is not a
> > 'developer', what is going on. Environments in R are not trivial
> knowledge
> > that can be raised too concisely).
>
> In some cases environments can be thought of like lists. As for how
> name look-up goes, yes it takes some studying to learn about that.
>
> > The reason why it mattered is because I am writing a program to be run on
> > our HPC, and I want it to abort when there is a warning so I can attend
> to
> > it right away. No point to discover after expensive usage that some
> warning
> > should be investigated, casting doubt on several days of computation. It
> is
> > also useful when writing recursive code, to abort immediately when the
> > warning list is populated as it is very hard to understand what went
> wrong,
> > and especially, where...
>
> This is a great programming strategy. You might be interested in one
> of my favorite recommendations: treat warnings like errors.
>
> options(warn = 2) # asks R to treat warnings as errors. See ?options
>
> As far as knowing more precisely where something went wrong (where not
> in the sense of what line of code, but in which function), consider
> using the traceback function. Or, in addition to the above options
> command, you might like:
>
> options(error = recover) # asks R to enter the debugger when there is an
> error
>
> and because warnings are now errors, it also enters the debugger for
> warnings. This way you can poke around where the warning occurred.
>
> > So, those were my motivations. Again, if I would know that I need a
> fresh R
> > session, I would get it. I don't like 'touching' what I don't
> understand. I
> > just wish I knew I needed to do so without wasting a day trying to debug
> a
> > warning, where all my actions to debug it were 'virtual'.
>
> I still don't see a need to manually access last.warning for the
> situation you described.
>
> > Again, thank you for your detailed response, I hope that the case I am
> > making is clearer now.
>
> Thank you for giving more details on what you're trying to accomplish.
>
> Scott
>
>
> --
> Scott Kostyshak
> Economics PhD Candidate
> Princeton University
>
> > Best regards,
> > Elad Zippory
> > Ph.D student
> > Politics, NYU
>
> > On Sat, Dec 28, 2013 at 9:19 PM, Scott Kostyshak <skost...@princeton.edu
> >
> > wrote:
> >>
> >> On Sat, Dec 28, 2013 at 6:06 PM, Elad Zippory <elad.zipp...@gmail.com>
> >> wrote:
> >> > Hi,
> >> >
> >> > I raised this issue at stackoverflow and it was suggested to raise it
> >> > here:
> >> >
> >> > >From the current help page, it is unclear that "warnings()" does not
> >> > clear
> >> > after rm(list=ls()). Currently the page states that:
> >> >
> >> > "Warning: It is undocumented where last.warning is stored nor that it
> is
> >> > visible, and this is subject to change. Prior to R 2.4.0 it was stored
> >> > in
> >> > the workspace, but no longer."
> >> >
> >> > Yet, I suggest that, if to keep the current behavior or until the
> >> > behavior
> >> > is changed, at least write explicitly in the help file something like
> >> > "clearing the global environment will not clear the warning list. To
> do
> >> > so
> >> > use assign("last.warning", NULL, envir = baseenv())"
> >> >
> >> > Thank you,
> >> > Elad Zippory
> >>
> >> Hi Elad,
> >>
> >> I'm not a decision maker around here but I'm curious about your
> >> suggestion. I always find it helpful to try to understand how people
> >> use R and how they expect R to work.
> >>
> >> From what I understand, you agree that there's no contradiction of
> >> behavior in terms of how R is documented to work and you agree that
> >> rm(list=ls()) should indeed not clear the warnings list. First, let me
> >> give my observation that I think the policy of writing R documentation
> >> is to give sufficient information for what a function does. When there
> >> is something surprising or there are performance issues to keep in
> >> mind, occasionally the R documentation appropriately mentions what a
> >> function does not do.
> >>
> >> I think you are interested in making more of a "let's make it easier
> >> on the user" argument so let me try to address that. I think it's easy
> >> to learn how to find the last.warning object. This would only require
> >> a user to read the first line of ?warnings and then to know about the
> >> getAnywhere function. That's it.
> >>
> >> In fact, I think that's too easy. I would personally be in favor of
> >> making it _more_ difficult for a beginning user to modify
> >> last.warning. I've never had to do such a thing and I would be
> >> suspicious of beginning/intermediate users who claim there's a need
> >> to. If you want a fresh R session, use a fresh R session. Clearing the
> >> global environment will not give a fresh R session. Clearing the
> >> global environment and clearing warnings will not do so either. In my
> >> opinion, it is tricks like these that can lead to unfortunate
> >> situations where results are not reproducible.
> >>
> >> Also, you mention a Stack Overflow question. If you are going to refer
> >> to something, please provide a link (perhaps in a footnote like this
> >> [1] if you do not want to put a long distracting URL in your message).
> >> Maybe there is no useful discussion there, but maybe there is and the
> >> discussion has already raised the points I raise in this email. The
> >> reader of your message is thus left wondering.
> >>
> >> Let me note that I'm just an ordinary R user. I hope I don't scare you
> >> off from giving more suggestions and wouldn't be surprised if others
> >> disagree. I hope you send more messages like the one you just sent
> >> because I'm interested in understanding what R users find confusing.
> >>
> >> Best regards,
> >>
> >> Scott
> >>
> >> [1] an old but related Stack Overflow question:
> >> http://stackoverflow.com/questions/5725106/r-how-to-clear-all-warnings
> >>
> >> --
> >> Scott Kostyshak
> >> Economics PhD Candidate
> >> Princeton University
> >
> >
>
[[alternative HTML version deleted]]
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
