What my R code looks and feels like (Vanilla)

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