The Art of R Programming review – part 8

(This article was originally published at Understanding the Data game, and syndicated at StatsBlogs.)

We're almost done with the book review! I've received hundreds of fan mail imploring that I continue, so I will. After which, I'll put the book reviews on hold for a bit and continue with my journey down the API road. That journey will also explore some of Python's features, rather than focusing solely on R as we have been. But we can cross that bridge when we get there. Now...onto the chapter review! Chapter 13 is about debugging (similar to, but not exactly of the IPM variety). While this topic doesn't get much love in other R intro books and summaries that I've seen, this author does it justice. It also helps that he co-authored the Art of Debugging. This post will lightly touch upon R's debugging tools, but, similarly to the post about Math and Stats in R, the tools are few, but the power lies in what you do with them*.

• The principle of confirmation is the essence of debugging (said by the book's author, not Confucius, but I can see why you might think that). That is, in programming one must confirm, line by line, what one believes to be true actually is true. When one of these confirmations is false, that serves as a clue to the location of the bug.
• One should begin debugging in a top down manner, also known as a modular approach to debugging.
• The first level code to be analyzed should be short and simple - just function calls. One should avoid functions within functions where possible.
• The author advocates using a debugging tool vs. the more manual, brute force approach of placing print() statements after every change in variable value and re-running the code.

Some of R's debugging facilities include:

• browser - Step through your code, line by line.
• debugonce(f) to step through a function, f, line by line.
• You can set breakpoints, which call the browser only when a certain condition is reached. For example, say you know that the code breaks down when your loop hits 100 iterations. Rather than going through each iteration in the debug mode, you can set the breakpoint condition to be if i > 99. Breakpoints are is used if you want to call browser somewhere in the middle of the function f, rather than only at the beginning (which is what debug(f) does).
• Other debugging features are traceBack and setBreakPoint
• In general, debugging has a steep learning curve, and many examples should be reviewed in order to get the hang of it.
• The author lists out several debugging packages recently created.
• Some warnings() that R spits out are actual errors in your code that R allows to execute without stopping you. Use warnings() to see detail on all the warnings in your code. Alternatively, set options(warn=2) to tell R to treat warnings as errors and fail to execute.

That's all I wanted to cover about this chapter. In all, I learned a lot about R's debugging tools, and am actively trying to incorporate a methodical and structured approach to debugging my code when possible.

Stay tuned for the final segment in the review. It's a biggie!

*ilan man, cerca 2013

Please comment on the article here: Understanding the Data game

Tags: books, R programming