On Sat, Dec 28, 2013 at 11:19 PM, Elad Zippory <elad.zippory at 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 <skostysh at princeton.edu> wrote:
On Sat, Dec 28, 2013 at 6:06 PM, Elad Zippory <elad.zippory at 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