I have a function that have nested functions. I call the sub functions inside the main function body, but the problem is that the methods such as head() or ggplot don't print to the command line. Is there any option in R to let those function print without nesting those functions inside print() method
x <- function(sample_dataframe){
y <- function(df){
head(df)
# do more stuff on the dataframe ..
return df
}
y(sample_dataframe)
}
x()
No, there isn't. The functions head() and ggplot() never print anything. They just return an object, and R decides whether to print that object or not.
The rule in R is that objects returned at the top level will print (unless they are marked as "invisible"). There's no option to make things automatically print in other circumstances.
The philosophy behind this difference is that R is intended to be used both interactively and programmatically. In a program, if you want something to print, you should call a function to print it. Weird automatic actions just cause trouble. However, this is inconvenient if you are using R more like a calculator than a programming platform. If you want to know the value of 123 times 456, it's a lot easier to type 123*456 than to type print(123*456), so the original interactive console would automatically print things unless you asked it not to do so.
In the years since that decision, things like R Markdown documents that blur the line between programming platform and interactive calculator have come along.
You find the programmatic requirement to specify your actions inconvenient: you'd like 123*456 in a program to print its result. The trouble with that behaviour is that there are functions in R that are called for their side effects (deleting files, opening graphics devices, etc.) and some of them return information that will print when they are called interactively, but will be ignored if they are called in a program. It is already inconvenient to have to use invisible() to suppress printing of function results; it would be even more inconvenient to have to use invisible() on every function call where you didn't save the result in a variable.
Related
I hope to know why message() is a better choice than print() when it comes to printing diagnostic messages.
For example, the print() function is a better choice to print R object such as 'iris', whereas, message() is better when we want to concatenate strings e.g. message("a", "b") is shorter than print(paste0("a", "b")).
However, I think there are more differences than those simple ones listed above. I have read the documentation for both methods
http://stat.ethz.ch/R-manual/R-devel/library/base/html/message.html,
http://stat.ethz.ch/R-manual/R-devel/library/base/html/print.html
but, it seems they are not as informative as I had hoped to my question.
I would appreciate if someone let us know in which case message() is better than print(), and why.
TL;DR
You should use cat() when making the print.*() functions for S3 objects. For everything else, you should use message() unless the state of the program is problematic. e.g. bad error that is recoverable gives warning() vs. show stopping error uses stop().
Goal
The objective of this post is to provide feedback on the different output options a package developer has access to and how one should structure output that is potentially on a new object or based upon strings.
R Output Overview
The traditional output functions are:
print()
cat()
message()
warning()
stop()
Now, the first two functions (print() and cat()) send their output to stdout or standard output. The last three functions (message(), warning(), and stop()) send their output to stderr or the standard error. That is, the result output from a command like lm() is sent to one file and the error output - if it exists - is sent to a completely separate file. This is particularly important for the user experience as diagnostics then are not cluttering the output of the results in log files and errors are then available to search through quickly.
Designing for Users and External Packages
Now, the above is framed more in a I/O mindset and not necessarily a user-facing frameset. So, let's provide some motivation for it in the context of an everyday R user. In particular, by using 3-5 or the stderr functions, their output is able to be suppressed without tinkering with the console text via sink() or capture.output(). The suppression normally comes in the form of suppressWarnings(), suppressMessages(), suppressPackageStartupMessages(), and so on. Thus, users are only confronted with result facing output. This is particularly important if you plan to allow users the flexibility of turning off text-based output when creating dynamic documents via either knitr, rmarkdown, or Sweave.
In particular, knitr offers chunk options such as error = F, message = F, and warning = F. This enables the reduction of text accompanying a command in the document. Furthermore, this prevents the need from using the results = "hide" option that would disable all output.
Specifics of Output
print()
Up first, we have an oldie but a goodie, print(). This function has some severe limitations. One of them being the lack of embedded concatenation of terms. The second, and probably more severe, is the fact that each output is preceded by [x] followed by quotations around the actual content. The x in this case refers to the element number being printed. This is helpful for debugging purposes, but outside of that it doesn't serve any purpose.
e.g.
print("Hello!")
[1] "Hello!"
For concatenation, we rely upon the paste() function working in sync with print():
print(paste("Hello","World!"))
[1] "Hello World!"
Alternatively, one can use the paste0(...) function in place of paste(...) to avoid the default use of a space between elements governed by paste()'s sep = " " parameter. (a.k.a concatenation without spaces)
e.g.
print(paste0("Hello","World!"))
[1] "HelloWorld!"
print(paste("Hello","World!", sep = ""))
[1] "HelloWorld!"
cat()
On the flip side, cat() addresses all of these critiques. Most notably, the sep=" " parameter of the paste() functionality is built in allowing one to skip writing paste() within cat(). However, the cat() function's only downside is you have to force new lines via \n appended at the end or fill = TRUE (uses default print width).
e.g.
cat("Hello!\n")
Hello!
cat("Hello","World!\n")
Hello World!
cat("Hello","World!\n", sep = "")
HelloWorld!
It is for this very reason why you should use cat() when designing a print.*() S3 method.
message()
The message() function is one step better than even cat()! The reason why is the output is distinct from traditional plain text as it is directed to stderr instead of stdout. E.g. They changed the color from standard black output to red output to catch the users eye.
Furthermore, you have the built in paste0() functionality.
message("Hello ","World!") # Note the space after Hello
"Hello World!"
Moreover, message() provides an error state that can be used with tryCatch()
e.g.
tryCatch(message("hello\n"), message=function(e){cat("goodbye\n")})
goodbye
warning()
The warning() function is not something to use casually. The warning function is differentiated from the message function primarily by having a line prefixed to it ("Warning message:") and its state is consider to be problematic.
Misc: Casual use in a function may inadvertently trigger heartbreak while trying to upload the package to CRAN due to the example checks and warnings normally being treated as "errors".
stop()
Last but not least, we have stop(). This takes warnings to the next level by completely killing the task at hand and returning control back to the user. Furthermore, it has the most serious prefix with the term "Error:" being added.
I hope to know why message() is a better choice than print() when it comes to printing diagnostic messages.
For example, the print() function is a better choice to print R object such as 'iris', whereas, message() is better when we want to concatenate strings e.g. message("a", "b") is shorter than print(paste0("a", "b")).
However, I think there are more differences than those simple ones listed above. I have read the documentation for both methods
http://stat.ethz.ch/R-manual/R-devel/library/base/html/message.html,
http://stat.ethz.ch/R-manual/R-devel/library/base/html/print.html
but, it seems they are not as informative as I had hoped to my question.
I would appreciate if someone let us know in which case message() is better than print(), and why.
TL;DR
You should use cat() when making the print.*() functions for S3 objects. For everything else, you should use message() unless the state of the program is problematic. e.g. bad error that is recoverable gives warning() vs. show stopping error uses stop().
Goal
The objective of this post is to provide feedback on the different output options a package developer has access to and how one should structure output that is potentially on a new object or based upon strings.
R Output Overview
The traditional output functions are:
print()
cat()
message()
warning()
stop()
Now, the first two functions (print() and cat()) send their output to stdout or standard output. The last three functions (message(), warning(), and stop()) send their output to stderr or the standard error. That is, the result output from a command like lm() is sent to one file and the error output - if it exists - is sent to a completely separate file. This is particularly important for the user experience as diagnostics then are not cluttering the output of the results in log files and errors are then available to search through quickly.
Designing for Users and External Packages
Now, the above is framed more in a I/O mindset and not necessarily a user-facing frameset. So, let's provide some motivation for it in the context of an everyday R user. In particular, by using 3-5 or the stderr functions, their output is able to be suppressed without tinkering with the console text via sink() or capture.output(). The suppression normally comes in the form of suppressWarnings(), suppressMessages(), suppressPackageStartupMessages(), and so on. Thus, users are only confronted with result facing output. This is particularly important if you plan to allow users the flexibility of turning off text-based output when creating dynamic documents via either knitr, rmarkdown, or Sweave.
In particular, knitr offers chunk options such as error = F, message = F, and warning = F. This enables the reduction of text accompanying a command in the document. Furthermore, this prevents the need from using the results = "hide" option that would disable all output.
Specifics of Output
print()
Up first, we have an oldie but a goodie, print(). This function has some severe limitations. One of them being the lack of embedded concatenation of terms. The second, and probably more severe, is the fact that each output is preceded by [x] followed by quotations around the actual content. The x in this case refers to the element number being printed. This is helpful for debugging purposes, but outside of that it doesn't serve any purpose.
e.g.
print("Hello!")
[1] "Hello!"
For concatenation, we rely upon the paste() function working in sync with print():
print(paste("Hello","World!"))
[1] "Hello World!"
Alternatively, one can use the paste0(...) function in place of paste(...) to avoid the default use of a space between elements governed by paste()'s sep = " " parameter. (a.k.a concatenation without spaces)
e.g.
print(paste0("Hello","World!"))
[1] "HelloWorld!"
print(paste("Hello","World!", sep = ""))
[1] "HelloWorld!"
cat()
On the flip side, cat() addresses all of these critiques. Most notably, the sep=" " parameter of the paste() functionality is built in allowing one to skip writing paste() within cat(). However, the cat() function's only downside is you have to force new lines via \n appended at the end or fill = TRUE (uses default print width).
e.g.
cat("Hello!\n")
Hello!
cat("Hello","World!\n")
Hello World!
cat("Hello","World!\n", sep = "")
HelloWorld!
It is for this very reason why you should use cat() when designing a print.*() S3 method.
message()
The message() function is one step better than even cat()! The reason why is the output is distinct from traditional plain text as it is directed to stderr instead of stdout. E.g. They changed the color from standard black output to red output to catch the users eye.
Furthermore, you have the built in paste0() functionality.
message("Hello ","World!") # Note the space after Hello
"Hello World!"
Moreover, message() provides an error state that can be used with tryCatch()
e.g.
tryCatch(message("hello\n"), message=function(e){cat("goodbye\n")})
goodbye
warning()
The warning() function is not something to use casually. The warning function is differentiated from the message function primarily by having a line prefixed to it ("Warning message:") and its state is consider to be problematic.
Misc: Casual use in a function may inadvertently trigger heartbreak while trying to upload the package to CRAN due to the example checks and warnings normally being treated as "errors".
stop()
Last but not least, we have stop(). This takes warnings to the next level by completely killing the task at hand and returning control back to the user. Furthermore, it has the most serious prefix with the term "Error:" being added.
I tried using a for loop to print out a few rows. here is the code.
Weird thing is that it doesn't work for head() function. It works if I replaced head() with print().
kw_id=c('a','b')
keyword_text=data.frame(col=c('a','b'), col2=c(1,2), row.names=(c('r1','r2')))
for (i in 1:2) {
plot_data<-subset(keyword_text,col==kw_id[i])
print(plot_data)
head(plot_data)
}
Could someone help? I suspect it has something to do with head() function.
This is a relatively common class of problem that newcomers to R run into. The issue here is that R serves two mistresses: interactive console work and "true programming".
When you type a command at the console that returns a value, the console automatically calls a print method in order to display the results. When running a script, this doesn't happen unless you tell it to.
So if you changed it to print(head(plot_data)) it should work.
These are discussed in FAQ 7.16 and 7.22
Addendum lifted from the comments:
As Josh points out, copy+pasting the for loop directly to the console also fails to print any output. What's going on in that case is that for loops (like most everything in R) is actually a function, and it's return value (NULL) is returned invisibly, which means no printing. (This is mentioned in ?Control.)
using R and debugging, I often might have a function with several arguments set by default.
e.g.
foo <- function(x=c(3,4,5), y= 'house', dateidx = '1990-01-01'){}
Often I just want to manually run through some lines in the function, while using the pre-set parameters. If the parameter list is long, I have to type or paste each argument to the console manually before stepping through the function.
x=c(3,4,5)
y= 'house'
dateidx = '1990-01-01'
It's ok if the list of arguments is small but if there is a long list of arguments, it gets tedious. Is there some way to just copy the whole set of arguments, paste to console, and do something like unlist, so that all the arguments are passed to the console as if I manually passed each one?
p.s. I'm weakly familiar with the debug tool, but sometimes I find it easier and faster to just troubleshoot lines quickly and manually as above.
There is no easy pre-existing way to do this--mainly because this a problem solved by the debugger.
One could imagine hacking something together that might parse these parameters with a regex and set them automatically--or something like that. However, the effort would be much better spent learning how to use the debugger.
It should be quite quick to test the part of the code you are interested in with the debugger if you learn how to use it. RStudio has a visual debugger. Using this, you can simply mark the command you are interested in testing with a breakpoint and run the script. The script will run until it reaches the breakpoint, then stop there so you can inspect what is happening.
Just suppose we are debugging a function foo(), and we want to modify it again and again and run it with some arguments - foo(bar="Hello", baz="How are you?") - to be sure the problem is solved.
After a modification of the foo() body, we run the lines of the function definition - to make the function modified - and now, we have to search over the history for the line containing foo(bar="Hello", baz="How are you?") to see if the modified foo() works properly.
Searching the history can also be replaced by continued pressing the "Up" key until it reaches before the function definition, when the last time we run foo(bar="Hello", baz="How are you?").
The other possibility is to keep foo(bar="Hello", baz="How are you?") in the clipboard and every time we modify the foo() body, we just paste foo(bar="Hello", baz="How are you?") from the clipboard and run it.
But all of these solutions are quite hard if we are modifying several functions with long bodies at the same time. The best possibility I have taught is to hide the function definitions from the history - when we are working with native R environment or with IDEs like RStudio. Is there any possibility to do this? Is there any better solution?
You can source() the function definition from file rather than "copy-paste" (or otherwise run) the function code block from the IDE/editor. Sourcing won't show in the R console if you do this (by default anyway). Most reasonable editors have a keyboard shortcut to source/load the function buffer/file/window into R via source() rather that by "pasting" - on Emacs+ESS it is C-c C-l for example.
You could use a sensible editor like Emacs with ESS which doesn't interleave code sent from code buffers into the R buffer, so you don't have to up-key back from the function definition, only back through the history.
At least on Linux you can use the common Ctrl+r and then start typing the first few characters of the function call you want, which will do a reverse search for the thing you are typing and then upon Enter will run that command/line.