The four efficiency measures described in this section can help with everyday coding problems. But they only go so far in helping you to process really large datasets (for example, datasets in the terabyte range). When you’re working with big datasets, methods like those described in appendix G are required.

Locating bottlenecks

“Why is my code taking so long?” R provides tools for profiling programs in order to identify the most time-consuming functions. Place the code to be profiled between Rprof() and Rprof(NULL). Then execute summaryRprof() to get a summary of the time spent executing each function. See ?Rprof and ?summaryRprof for details.

Efficiency is little comfort when a program won’t execute or gives nonsensical results. Methods for uncovering programming errors are considered next.

20.5 Debugging

Debugging is the process of finding and reducing the number of errors or defects in a program. It would be wonderful if programs worked the first time. It would also be wonderful if unicorns lived in my neighborhood. In all but the simplest programs, errors occur. Determining the cause of these errors and fixing them is a time-consuming process. In this section, we’ll look at common sources of error and tools that can help to uncover errors.

20.5.1Common sources of errors

The following are some common reasons functions fail in R:

■An object name is misspelled, or the object doesn’t exist.

■There is a misspecification of the parameters in a function call.

■The contents of an object aren’t what the user expects. In particular, errors are often caused by passing objects that are NULL or contain NaN or NA values to a function that can’t handle them.

The third reason is more common than you may think. It results from R’s terse approach to errors and warnings.

Consider the following example. For the mtcars dataset in the base installation, you want to provide the variable am (transmission type) with a more informative title and labels. Next, you want to compare the gas mileage of cars with automatic transmissions to those with manual transmissions:

> mtcars$Transmission <- factor(mtcars$a, levels=c(1,2),

labels=c("Automatic", "Manual")) > aov(mpg ~ Transmission, data=mtcars)

Error in `contrasts<-`(`*tmp*`, value = contr.funs[1 + isOF[nn]]) : contrasts can be applied only to factors with 2 or more levels

Yikes! (Embarrassing, but this is actually what I said.) What happened?

You didn’t get an “Object xxx not found” error, so you probably didn’t misspell a function, data frame, or variable name. Let’s look at the data that was passed to the aov() function:

There are no cars with a manual transmission. Looking back at the original dataset, the variable am is coded 0=automatic, 1=manual (not 1=automatic, 2=manual).

The factor() function happily did what you asked without warnings or errors. It set all cars with manual transmissions to automatic and all cars with automatic transmissions to missing. With only one group available, the analysis of variance failed. Confirming that each input to a function contains the expected data can save you hours of frustrating detective work.

20.5.2Debugging tools

Although examining object names, function parameters, and function inputs will uncover many sources of error, sometimes you have to delve into the inner workings of functions and functions that call functions. In these cases, the internal debugger that comes with R can be useful. Some helpful debugging functions are listed table 20.1.

Table 20.1 Built-in debugging functions

486 CHAPTER 20 Advanced programming

if (low && high)

stop("'low' and 'high' cannot be both TRUE") n2 <- n%/%2 + as.integer(high)

sort(abs(x - center), partial = n2)[n2]

First, the arg() function is used to display the argument names and default values for the mad() function b. The debug flag is then set using debug(mad) c. Now, whenever mad() is called, the browser() function is executed, allowing you to step through the function a line at a time.

When mad() is called, the session goes into browser() mode. The code for the function is listed but not executed. Additionally, the prompt changes to Browse[n]>, where n indicates the browser level. The number increments with each recursive call.

In browser() mode, other R commands can be executed. For example, ls() lists the objects in existence at a given point during the function’s execution d. Typing an object’s name displays its contents. If an object is named n, c, or Q, you must use print(n), print(c), or print(Q) to view its contents. You can change the values of objects by typing assignment statements.

You step through the function and execute the statements one at a time by entering the letter n or pressing the Return or Enter key e. The where statement indicates where you are in the stack of function calls being executed. With a single function, this isn’t very interesting; but if you have functions that call other functions, it can be helpful.

Typing c moves out of single-step mode and executes the remainder of the current function f. Typing Q exits the function and returns you to the R prompt.

The debug() function is useful when you have loops and want to see how values are changing. You can also embed the browser() function directly in code in order to help locate a problem. Let’s say that you have a variable X that should never be negative. Adding the code

if (X < 0) browser()

allows you to explore the current state of the function when the problem occurs. You can take out the extra code when the function is sufficiently debugged. (I originally wrote “fully debugged,” but this almost never happens, so I changed it to “sufficiently debugged” to reflect a programmer’s reality.)

20.5.3Session options that support debugging

When you have functions that call functions, two session options can help in the debugging process. Normally, when R encounters an error, it prints an error message