What my R code looks and feels like

What my R code looks and feels like (Vanilla) Geoff Robinson CSIRO Mathematics, Informatics and Statistics 1

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 La. Te. X 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 2

Structure of the talk • Nexamples <- 6 • for (i in 1: Nexamples) { – Show portion of code – Explain a feature – browser() • } 3

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 4

Ex 2: R code behind a (La. Te. X) 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 “To. File” are for the report. – Other graphs are for checking data and approach – These graphs + comments are your first draft • I make use of La. Te. X commands like: – newcommand{Rcode}[1]{} – newcommand{FIGURE}[2]{parbegin{figure}[htp] begin{center}includegraphics{Graphs/#1} caption{#2}label{#1}end{center}end{figure} par} 5

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. 6

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. 7

Ex 5: A La. Te. X report for each of many companies • Rather than using Sweave, I use my own functions for writing bits of input to La. Te. X tables – Easier for a vanilla-biased person (me) to get to work • File of La. Te. X source on One. Company. tex – Reads a file first. tex to read values of some variables – Company-specific table on file table 3. tex – Company-specific graphs on files with names like comp_No. Changes. Cargo. Tonnes. pdf • Run La. Te. X twice and rename the. pdf file produced • Logical structure is transparent 8

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 Rinterface function 9

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 10