1

What my R code looks and feels like(Vanilla)

Geoff Robinson CSIRO Mathematics, Informatics and Statistics

2

Basic philosophy

• Right by the third time!

• Assume that priorities, the problem and the data will all get changed

• I eat vanilla ice-cream and add my own fruit.– I use few LaTeX packages and few R packages

• I hope to be able to read old code and– Remember how to use it– Remember what it did– Be able to change it to do a slightly different job– Have confidence that it is doing sensible things

3

Structure of the talk

• Nexamples <- 6

• for (i in 1:Nexamples) {– Show portion of code– Explain a feature– browser()

• }

4

Ex 1: Issues when writing a function

• What task do I want this function to do?

• What do I want returned?

• When should this function fail? … Message???

• Does this function need to work for vector arguments?

• How can I be sure that the function is correct?– Retain testing code

• … You can easily add parameters with default values to a previously-defined function

5

Ex 2: R code behind a (LaTeX) report

• Write figures in a small number of standard formats

• Do not change data on raw data files!– Keep commands to check reasonableness and make

changes

• Graphs saved using “ToFile” are for the report.– Other graphs are for checking data and approach– These graphs + comments are your first draft

• I make use of LaTeX commands like: – \newcommand{\Rcode}[1]{}– \newcommand{\FIGURE}[2]{\par\begin{figure}[htp]

\begin{center}\includegraphics{Graphs/#1}\caption{#2}\label{#1}\end{center}\end{figure}\par}

6

Ex 3: Using R for prototyping, research and algorithm development

• Confidence that the answers are correct is most important– More important than computational efficiency– Another version of the code and be more efficient and can

be checked against the first version

• The Kalman Filtering code shown– Uses notation corresponding to the referenced paper– Ignores the fact that several matrices are often sparse and

indeed are often identity matrices– Is not computationally efficient– Is reliable for checking answers produced by other code.

7

Ex 4: Functions likely to be reused

• Keep on a separate file

• Use environments for serious sets of functions– Use of global memory is bad programming practice– Force yourself to think about which functions belong in

which groups

• Aim to (eventually) end up with the set of commands which you would have written if you had been clever

• Keep test data with code. Comment it out or put it inside if(FALSE){ }– This has a different purpose from the package RUnit. It is

useful when the function is modified, extended or changed in scope.

8

Ex 5: A LaTeX report for each of many companies

• Rather than using Sweave, I use my own functions for writing bits of input to LaTeX tables– Easier for a vanilla-biased person (me) to get to work

• File of LaTeX source on OneCompany.tex– Reads a file first.tex to read values of some variables– Company-specific table on file table3.tex– Company-specific graphs on files with names like

comp_NoChangesCargoTonnes.pdf

• Run LaTeX twice and rename the .pdf file produced

• Logical structure is transparent

9

Ex 6: Interfacing C (or Fortran) and R

• Have an interface function in C that does very little except call other C functions

• Have an interface function in R that does very little except check its arguments and call the C-interface function

• The C-interface function is only called from the R-interface function

10

Repeating my basic philosophy…• Right by the third time!

• Assume that priorities, the problem and the data will get changed

• I hope to be able to read old code and– Remember how to use it– Remember what it did– Be able to change it to do a slightly different job– Have confidence that it is doing sensible things– Other people should also find it readable

• Don’t hide your programming style even if you are ashamed of it– And show off when you are proud of something– Life is too short to only learn from your own mistakes