The Problem: Create a basic 1970s style Pong game for one player using the Processing programming language. The paddle will be on the right and the ball will bounce off of the three other sides. If the ball passes the paddle while the ball is traveling to the right, game play ends. The paddle will be controlled by the keyboard’s UP and DOWN arrow keys.

The purpose of this article is to present my problem solving process as I create Pong. I’m going to deliberately walk through the process as a novice programmer might. Students rarely get to see how their instructors think through a problem, unless the instructor live-codes in front of them. But, even then, students are confused by the changing dynamics of the solution as the instructor begins to understand the problem better and refactors his or her code in real-time.

First, let me make sure I understand the problem space. A quick diagram often helps:

• There’s a playing field of some unspecified dimensions
• there’s a ball (a circle)

Ok, that seems like a good start. Now, let me do the simplest thing that can possibly work to represent what I know about the game. In Processing, there’s a standard skeleton for basic programs:

Now, let me create the playing field (window) in the setup method and create a ball (circle or ellipse) in the draw method. The Processing reference manual tells me that when drawing an ellipse, the default drawing mode assumes that the ellipse method takes four arguments: x and y coordinates for the center of the ellipse and width and height values for the horizontal and vertical diameters of the ellipse.

Further, the setup method is executed just once, before the program gets started. The draw method is an implicit loop in Processing; it gets called many times per second to redraw the window.

If I run my code, I get a 400 by 400 pixel window and a circle located at (20,20) that is 20 pixels wide and 20 pixels high, but so far, it just sits there.

• the ball moves from left to right

Well, that implies that the x and y coordinates of the ellipse need to vary, so I’m going to need to refactor my code to use variables for the x and y coordinates of the ball. When I refactor, I want to reorganize my code, but not change the functionality: the code should be organized better, but the program should do the same thing. I like to use obvious variable names, so my code is easy to read and understand, so I’ll use “ballX” and “ballY”. (nota bene: when you find yourself prefixing variable names with the name of objects you’re manipulating, it suggests strongly that you should consider object-oriented design/programming.)

I run my code again, and indeed it behaves exactly the same as it did before the refactor. Now, I’ll add the least code I can to get the ball to move from left to right a little bit each time it’s drawn. It’s often difficult for novices to break down a task like “move the ball to the right side of the screen” into the smaller, discrete steps necessary to get the task done. The key, I think, is to think of a loop (in this case, the implicit loop of the draw method) like a flipbook animation from your childhood. You’re not going to just magically have the ball appear at the right edge of the window. Instead, you’re going to move the ball just a little toward the right edge each time it’s drawn.

It’s probably best for me to think about how much of a change I want ballX to undergo during each drawing cycle. It’s customary to refer to a small change in x as “dX”, the “delta x” or “change in x” value. Since x represents the number of pixels from the left edge of the window, adding just 2 pixels to the ball’s location each time it is drawn should have a smooth animation effect. So, I’ll set the initial value of dX to 2 and add dX to ballX each time the draw method is executed.

When I run my code, the ball moves!! Not well, but… it moves! Each drawing of the ball is being left on the playing field. In Processing, to start each drawing cycle with a clean window, you set the background of the window. Here, I’ll set it to a solid color using the RGB color model: (255, 255, 255), which is the value I want for red, green, and blue components of the color. Setting them all to 255 causes the background to be white.

When I re-run it, the ball now moves cleanly… and keeps moving, right off the right side of the window. I want to add code that says that if the ball reaches the right side of the window, it should move back the other way. That’s not ultimately how game play will work, but I want to be able to see the ball moving around successfully, before I worry about how the game ends. I know that in this particular case, the right side of the window is at x coordinate 400, because that’s how big I made the window in the setup method. So, if the ball’s x position reaches (or passes) 400 pixels, I’ll reverse the direction of the change (dX). If a dX value of 2 moves the ball 2 pixels to the right, then a dX value of -2 would move the ball 2 pixels to the left. So all I should need to do is change the sign of dX (lines 13-15). Notice that I’ve added a comment at line 14 using the // notation. Generally, comments should describe why you’re writing the code, not how; the code itself tells me how.

If I run the code, I get a ball that bounces off of the right side of the window, then disappears off the left side!

• the ball bounces when it hits the left of the playing field

Well, I know that the left side of the window is at x coordinate 0 (zero), so I can repeat my code that handles bouncing on the right side (lines 13-15) and change it a little to handle bouncing on the left side of the window.

This seems to give me the bouncing ball I want, but I’m bothered by the magic number 400 I’ve used at line 13. In general, I won’t know how wide or high the playing field window is. I need to use a variable that represents the width of the window and, fortunately, Processing provides such a variable for me already: width.

So far, I’ve only addressed the ball’s movement left and right. It doesn’t move up and down at all. Let me write a few lines of code (lines 4 and 23, below) just the way I’ve handled dX and create a dY variable that behaves similarly.

Well that seems OK… the ball bounces from the upper-left corner to the lower-right corner, but it’s not very interesting. Let me spice things up a little by changing the magic numbers I’ve used for dX and dY to random numbers in the range [+1..+2] at lines 3 and 4.

When I run it a few times, I notice that the ball works well, if it happens to reach the right and left sides of the window, but when it reaches the top or bottom of the window, it disappears. I can add two additional if statements similar to the two I already have, but this time they’ll work with the variables ballY and dY. Also, the new code (lines 22-28, below) doesn’t need to know about the width of the window, but it does need to know about the height of the window and, again, Processing provides us with a convenient variable named height.

• the ball bounces when it hits the top of the playing field
• the ball bounces when it hits the bottom of the playing field

Alright, now that the ball seems to be moving around well, I’ll turn my attention to the paddle.

• there’s a paddle (a rectangle) near the right of the playing field

I’m going to make some assumptions about the placement of the paddle. First, it won’t be touching the right side of the window. Second, it will be 10 pixels wide and 30 pixels tall. I’m also placing it arbitrarily 10 pixels from the top of the window. I’m pulling these numbers out of thin air (they’re magic numbers), so I may well need to change them or replace them with variables later.

So, now I have an unmoving, inert paddle! Well, it’s progress… I’ll deal with the movement of the paddle, first. I know that I want to change the vertical position of the paddle, which is its y coordinate. So far, the position of the paddle has been hard coded with the magic number 10 (in line 14, above). I’ll need to refactor that into a variable, since its value will change over time, much like ballX and ballY. I’ll call it paddleY, to be consistent and obvious.

To be completely consistent, I’d like to replace my magic use of “width – 15″ (line 15, above) with a variable (line 17, below), too. It’s the x coordinate of the paddle, so I’ll create a paddleX variable, just like the paddleY variable. I’m going to run into one problem, though. The variables I define (lines 1-6, below) are declared and initialized before the setup method executes. That means that the size of the window hasn’t been set yet (line 8), so I can’t initialize the value of paddleX, since it’s determined relative to the width of the window. I can only declare my intention to use it (line 5). Later, after the size of the window has been set (line 9), then I can initialize the value of paddleY (line 10) and replace my magic number with the variable (line 17).

• the paddle can move up and down using the keyboard’s UP and DOWN arrow keys as input

Let’s deal with the problem of having the paddle respond to key presses, now. I do a quick search of the Processing Reference web pages and find some example code for the keyCode property that is close to what I want to do.

In their example, pressing the arrow keys results in a changed fill color (lines 10-14, above). For my pong game, I want the arrow keys to change the value of paddleY, the paddle’s vertical position. The variables, draw method (1-6), and else statement (lines 11-13) from the example are irrelevant to my pong game.

As a programmer I often need to find examples of how a task is performed in a given language, and then modify the example to match my circumstances better. When I do that, it’s good practice to add a comment explaining where I got the original code and acknowledging that it’s not my original creation. First, it provides me and other programmers with a road map, if I or they ever need to maintain the program I’ve written. Second, it makes clear which parts of the code are my original creation and which I’ve borrowed from other sources. If I were writing an English essay, I would use quotation marks and proper citations. When writing code, I add comments and provide URLs, email addresses, etc. to cite my sources.

I have once again put in some magic numbers: 30 at lines 17, 43, and 45, above. It’s the paddle height, but that’s not obvious from the code. So, let me refactor that to a variable.

Now that we have a paddle, we want to reconsider when the ball should bounce on the right side of our window. As the code is written, it bounces with it reaches the edge of the window itself, but we want it to bounce when it reaches the left-hand face of the paddle, which is located along a vertical line located at paddleX. I’ve updated line 20, below.

But that’s not the end of the story. As it’s written, the ball will bounce when it reaches the invisible vertical line, even if it isn’t touching the face of the paddle.

• the ball bounces when it hits the paddle (approaching from the left)

So, we need to update line 20 so that we check not only the horizontal position of the ball (which we’ve been doing all along), but also the vertical position of the ball with respect to the vertical position of the paddle.

I’m getting nervous about the complexity of the logic on line 20; other programmers (including my future self!) may not understand what my intention was in writing that code. In fact, I haven’t really given a name to what it is I’m trying to do on that line! A large part of programming is communication. As a programmer, I’m trying to communicate my intentions not only to the computer, so that it can execute them, but also to other programmers who may read my code. I’ve tried to create a domain specific set of variable names (ballX, ballY, dX, dY, paddleX, paddlyY, and paddleH) to make my code more readable by humans. If I only cared about the computer understanding my code, I could just as easily have used bX and bY or iLoveRockAndRollX and iLoveRockAndRollY. But humans (me, my instructors, my students, my friends, my future employers) need to read the code, too, so I’d like to make it as understandable as possible.

With that in mind, I’m going to extract the logic from line 20 into its own method with a method name that makes my intentions clear(er). My new method will return a boolean value (either true or false) depending on whether there has been a collision.

The collision method, so far, is still not transparent to the casual reader. I’d like to refactor the code within that method to make my intentions clearer.

That refactoring has revealed a problem with my thinking. So far, I’ve been testing only that the ball is to the right of the left-hand face of the paddle. If the ball somehow managed to get BETWEEN the right edge of the window and the paddle, it would still count as a collision and the ball would start back toward the left. I’ve noticed this because my testing of the horizontal position of the ball at line 42 isn’t parallel to my testing of the vertical position of the ball at line 43. In other words, I’m testing that the ball is between the top and bottom of the paddle, but I’m only testing that it’s to the right of the left-most side of the paddle.

In order to fix this, I need to know how wide the paddle is. Unfortunately, I’ve left that as a magic number (10) at line 18, until now. I’ll extract that to a variable (paddleW) and update my collision method to incorporate that at line 43.

Finally, I want to end the game, if the player missed the paddle.

• the game ends when the ball reaches the right of the playing field

I notice that, if the ball’s x coordinate is greater than the window’s width, then the ball must have passed by the paddle, so the game should end. There are other possible conditions you might use, but this one seems simple and obvious, at the moment.

I have also noticed that by using the ball’s x and y coordinates in my collision method, and leaving the default ellipse drawing mode set to CENTER, it’s actually the center point of the ball that I’m using as the hot spot (have you hit the wall? have you hit the paddle?) when I should probably be using the ball’s left-, right-, top-, and bottom-most points as the hot spots.

In order to be able to compute the left-, right-, top-, and bottom-most points of the ball, I’m going to need to know the radius of the ball (or, equivalantly the diameter). Unfortuneately, I again left that as a magic number (line 16, above), so I’ll first need to refactor that and extract the radius to a variable (lines 3, 18).

Now, I can add methods that compute the bounds of the ball on demand (lines 58-72).

It’s usually good practice when refactoring to only change one thing at a time (i.e., only add one new method, only change one variable name, etc.) and then retest your code. That way, you limit the range of mistakes, typos, logic errors, etc. that you might make at any one time.

So, I’ll begin by finding all the lines of code that I intended to refer to the right-most point of the ball. It seems that lines 22 and 50 should be my targets.

Now, I’ll find all the lines of code that I intended to refer to the left-most point of the ball. It seems that lines 32 and 50 should be my targets.

Test my code to confirm it’s still functioning, and then I’ll find all the lines of code that I intended to refer to the top-most point of the ball. It seems that lines 40 and 51 should be my targets.

Test my code once more to confirm it’s still functioning, and then I’ll find all the lines of code that I intended to refer to the bottom-most point of the ball. It seems that lines 36 and 51 should be my targets.

There are additional features I’d like to add (the ability to reset the game or to use mouse input, for example) and refactorings I’d like to make (turn this into an object oriented program), but this is a working, playable game at this point that solves the problem, as stated. A well-trained programmer will no doubt be appalled at the coding style, but I’ve intentionally tried not to use shorthand notations or to introduce solutions or idioms that would be unfamiliar to the novice programmer.

The fact that I have multiple methods (setup, draw, keyPressed, and now collision) that are all accessing the same variables raises a serious concern for me as does my use of special methods to handle pseudo-properties of the ball (ballTop, ballBottom, ballLeft, ballRight). How can I hope to keep track of where variables are used and modified? I’m making my code difficult to maintain and understand by using instance variables all over the place. A better solution would be to use object-oriented programming techniques so that I can encapsulate the variables and behaviors related to the ball within an object (perhaps named Ball) and encapsulate the variables and behaviors related to the paddle within another object (named Paddle). I’m going to set aside my misgivings for now and leave the refactoring of this code into an object-oriented structure for another blog post.

I’d like to give a brief overview of computational efficiency, since it’s a topic that has come up in a few conversations recently. The super short version is this: it’s often helpful to understand the resource (time, space, or power) needs for a given algorithm. Why? Because we want the fastest algorithm, or the one that uses the least amount of storage on our hard drive. In extreme computing environments (think Mars Rover, Apollo capsules, etc), we many have very limited resources available. For example, your digital wrist watch almost certainly has more memory than the Apollo capsules, which only had about 32KB of RAM. How can you possibly land a person on the moon with only 32KB?!!

So, how do we measure the resource use of a given algorithm? Essentially, we decide how much of a resource is used for each “step” in the algorithm, then try to count the number of steps the algorithm will perform. Suppose we had a very simple algorithm:

With a few simplifying assumptions, it’s probably safe to say that this would require just 1 step to perform, namely the step of displaying the value 1. Meanwhile, a similar, yet slightly more complex, algorithm such as

would likely require 2 steps: 1 step to look up the value of x and 1 step to display the value. Here, I’m assuming that the variable x has already been assigned a value, which would have taken a little work, as well.

Taking it one step further (ha!), consider the slightly more complex example of

How many steps would that take? Well, looking up the value of x is still 1 step, plus 1 step for the addition operation, plus 1 step to display the result of the addition. So, 3 steps in total. This assumes that you have a sensible computer at your disposal where addition only needs 1 step to complete.

Again, let’s make it a little more complicated and consider

Now, multiplication, unlike addition, is usually a two step (or more!) operation. Why is that? Well, for simple addition problems, computers have a straightforward solution to solving the problem. But multiplication is a more complex process, as any 4th grader will tell you. One way to think of multiplication, in the general case, is as repeated addition. So, x * 4 is the same as x + x + x + x. But if addition is a 1 step process, then that approach to multiplication would require 4 steps! Fortunately, computers have better algorithms for multiplication than our grade school teachers taught us. Still, multiplication takes more steps than addition, so for the sake of argument, let’s say it’s 2 steps per multiplication. You can probably imagine what would happen with exponentiation!

In short, every operation that the computer must perform takes time, which in the abstract we can think of as steps. Looking up a value is an operation, storing a value is an operation, displaying a value, adding, multiplying, and even just waiting– they’re all operations. We can count the number of operations to be performed (not always as trivial as I’ve made it here) and use the total number of steps as a measure of efficiency.

Some algorithms take constant time to execute. Looking up the first entry in a phone book, for example, will always take the same number of steps, regardless of how big the phone book is.

Other algorithms will vary, based on the size of the input (i.e., how big the phone book is). For example, counting the number of people named Jane in the phone book is relatively easy in a very small town, but very hard in a large city! In computer science terms, we say that the input to an algorithm is of size n (i.e., how many names in the phone book, in this case). When n is big, the algorithm takes more steps.

For very large data sets, the difference between an algorithm that executes in 1 step versus an algorithm that requires n steps (where n varies on the size of the input) is a huge difference. Finding the first name in the phone book in New York City is as easy as finding the first name in the phone book in Smalltown USA.

In computer science we would say that asking “what is the first” is O(1) (read: “big-Oh of 1″ or “on the order of 1″) and asking “how many are there” is O(n) (read: “big-Oh of n” or “on the order of n”).

O(1) algorithms execute in a constant number of steps (the time to execute it doesn’t vary when the input size varies). For example, “what is the first (or last) element?” is an O(1) question… no matter how large the input is, finding the first (or last) element is easy.

O(n) algorithms execute in n steps (the time to execute it DOES vary when the input size varies). For example, “what is the maximum (or minimum) value in a given list?” is an O(n) question… generally, you have to inspect every element in the list to be able to answer it. If you happen to know a priori that the list is sorted (a special case), then finding the minimum or maximum reduces to finding the first or last element in the list, respectively, making it an easy question — but you have to get the vector sorted, first.

There are many other orders of complexity: O(log(n)), O(n/2), O(n²), O(n³), O(n!), and so on. Something that’s O(n!) will take a very large number of steps, even for small values of n (the factorial function grows very quickly!).

In short, understanding something about the number of steps a given algorithm will take to solve an instance of a problem can help us choose among different algorithms that all produce the same result, but where some solutions are more efficient than others.

Alfred Thompson questioned on his blog today whether the customary first programming exercise, Hello World, should be replaced with something that’s more flexible and calls on students to engage in a short, non-trivial first act as a programmer. I admit, I’ve used Hello World myself with students, but usually not as a first activity. Instead, I use Hello World to help students who have had some hours or days of programming instruction understand that they now know quite a bit about how programming languages express an intention. I ask students to visit the ACM Hello World web page and compare and contrast that simple program in different languages. How are code blocks started and ended? How is output generated? How is an infinite loop expressed? How are strings represented?

But to address the primary question Alfred poses, should we use a different first exercise, I’d say yes. I’ve used a constructive series of exercises in JavaScript that builds on the idea of rolling dice and a number guessing game for several years with great success and enthusiasm from students.

The first example I offer introduces an activity with which students are already familiar: rolling a single die. Students understand that we’re trying to generate a number from 1 to 6 (inclusive) and to let the user know the generated number.

This example allows us to discuss how a function is called (Math.random and Math.floor), the use of the asterisk to denote multiplication, what the outputs of those functions are, and the order of operations, grounded in their prior knowledge about algebra. It also introduces the use of a scalar variable, output, and concatenation; all of that in just two lines of code.

However, the example is necessarily constrained. Users must reload a web page to see a different number generated and there’s no input from the user. Adding just a few lines of code, we address those issues in the second exercise.

This exercise also allows me to introduce conditionals, the use of == as the equality predicate, and basic data types via the  user string input needing to be converted to an integer. Still, however, the page must be reloaded for each guess, which causes a new random number to be generated, thus making it a game you can only win if your first guess happens to be correct. This allows us to talk about the life cycle of the interpreted code and motivates the need for loops.

Each of these exercises builds on the previous examples by adding just one or two new ideas and lines of code, so that students can see the logical development of the code and so that each new idea is motivated by a desire to improve game play, for example, by subtly introducing != as a “not equals” predicate. Students are free to experiment with the range of numbers and the details of the feedback provided to users. Once we’ve got a reasonably playable game, we can refactor the upper and lower limits of the game to variables.

This refactoring is motivated by students’ desire to quickly change the game’s parameters so that they each have a slightly different version of the game (guess a number between 1 and 10,000,000 isn’t uncommon!).

This allows us to discuss whether the same code would work, if the range were to include negative numbers (-10…10, for example), or fractional numbers (-0.5…0.5, for example; hint: Math.floor might cause problems), or if we wanted to generate richer feedback to users.

In short, I lead students to these examples by providing the motivating context and introducing the new language features just in time. Students get to interact with a fairly interesting first game and to push at the edges of what can be achieved from that simple code base.

Imagine for a moment that you were going to teach writing in standard English in the same way we tend to teach computer programming.

Alright… Let’s learn to write. Before you can write, you need to know about the fundamentals of the language we’re going to use. A language is a collection of words and rules for how you combine those words. Words can be thought of as being of different types that determine the purpose and meaning of the words. For example, two types we’ll work with are nouns and interjections. There are other types, too, but we’ll get to those later.

For now, let’s write your first sentence. A sentence is a valid sequence of words. By valid we mean that the sentence would be recognized by an expert speaker of the language as being acceptable.

So, we need an example of a noun and an interjection to get us started… One frequently used noun is the word WORLD and a common interjection is HELLO.

The students, if dutiful, carefully take in the presentation, try to memorize the new terms you’ve introduced, and set about trying to write their first sentences.

WORLD HELLO

error: unexpected token at line 1: WORLD

HELLO WORLD

error: unexpected token at line 1: WORLD

Having exhausted the possible combination of the words, we introduce additional notational constraints

Well, it turns out that written English requires some additional syntactic sugar in order to be valid. We need to introduce punctuation into out writing, such as commas and periods.

and students set to work

HELLO, WORLD

error: unterminated string at line 1

HELLO, WORLD.

compilation successful

Now, what’s wrong about this process? How could it be made better?

Eric Freudenthal of the iMPaCT: a Media-Propelled introduction to Computational Thinking project spoke at SIGCSE 2010 about how to engage students who are math phobic with computation and, thereby, with math. Using Python and computation about dynamic systems, students work to understand how code == math == concepts. One issue raised was how ethical it is to mislead students initially about whether they’re learning “math”. Eric’s argument: if students know they’re learning math, they fallback on unsuccessful rote memorization techniques. If, however, they believe they are working with dynamic systems to understand how the system changes as parameters are adjusted, then students engage and experiment.

Every programmer and programming language has a preferred variation on how to format code. Here are my best suggestions for the languages I tend to code.

• Use spaces, not tabs. The definition (display width) of a tab can vary from one editor and platform to the next. A space is always a space.
• Use two (2) spaces to indent a block of code.
• Always wrap code blocks with curly braces { } even if they’re optional for a single line of code. Someone will, eventually, want to add a second line of code to the block and will, as a rule, forget to add the curly braces.
• The opening curly brace of a block should be on the same line as its opening statement.

      public String getFirstname () {
      while (i < 5) {
  

• The closing curly brace should be on its own line.

      }
  

• Leave a blank line after closing a block of code (including the end of a method), unless followed immediately by another closing curly brace.

              }
            }
          }
  

• Place a comment after closing a block of code when there’s a series of closing curly braces.

              } // if
            } // method
          } // class
  

• always put one (1) space before and after binary operators.

      x = x + 5;
      while (i < 5) {
  

• Put one (1) space before the opening parenthesis and after the closing parenthesis in statements (for, while, if, and so on) or function calls.

      for (int i = 0; i < 100; i = i + 1) {
      while (x != 2) {
      if (isPrime (n)) {
      sin (5)
      getPrice ()
  

• Indent each new code block.

      for (int i = 0; i < 100; i = i + 1) {
        if ((i % 2) != 0) {
          if (isPrime (i)) {
            System.out.println (i);
          } // if
        } // if
      } // for
  

• Use the variable naming convention used in your language of the moment: camelCase or under_scores.
• Use meaningful variable and method names. For method names, verbNoun them.

      numStudents
      totalVacationDays
      getFirstname ()
      computeSalary ()
  

• Use single letter variable names iff the letter reflects a standard (recognizable) convention.
  • i, j, k for an index (counter) variable
  • x, y, z for coordinates in 3-space
  • a, b, c for coefficients
  • m, n for the number of items in a collection
  • r for the radius of a circle
  • w, h for the width and height of an object
• Use ALL_UPPERCASE for constants (fixed values, like PI)
• Use white space to make your code more readable.
• Comments should describe why you’re doing something, not how. The code tells me how you’re doing it.

The R Project provides a comprehensive, free, open source statistical programming language and environment based on the S language. R is the name of both the language and the environment in which you generally use the language. It’s an interactive environment where the commands you enter generate immediate results that you can use to guide your analyses.

> x <- c(5,4,3,2,5)
> mean(x)
3.8

There is an active development and support community using R and it’s been growing more popular in both academic and business communities.

Books & Articles on R

• Albert, J. (2009). Bayesian computation with R (2nd ed.). New York: Springer.
• Baayen, R. H. (2008). Analyzing linguistic data : a practical introduction to statistics using R. Cambridge, UK ; New York: Cambridge University Press.
• Braun, J., & Murdoch, D. J. (2007). A first course in statistical programming with R. Cambridge ; New York: Cambridge University Press.
• Crawley, M. J. (2007). The R book. Chichester, England ; Hoboken, N.J.: Wiley.
• Dalgaard, P. (2008). Introductory statistics with R (2nd ed.). New York: Springer.
• Gentle, J. E. (2009). Computational statistics. New York: Springer.
• Good, P. I. (2005). Introduction to statistics through resampling methods and R/S-PLUS. Hoboken, N.J.: Wiley-Interscience.
• Leipzig, J., & Li, X.-Y. (2009). Data mashups in R. from http://oreilly.com/catalog/9780596804770/
• Nolan, D. A., & Speed, T. P. (2000). Stat labs : mathematical statistics through applications. New York: Springer.
• Owen, W. J. (2006). Using R in an Undergraduate Mathematical Statistics Sequence [Electronic Version]. InterStat, from http://interstat.statjournals.net/YEAR/2006/abstracts/0605002.php
• Owen, W. J. (2007). The R Guide [Electronic Version], from http://cran.r-project.org/doc/contrib/Owen-TheRGuide.pdf
• Petris, G. (2009). Dynamic linear models with R. New York: Springer.
• Rossiter, D. G. (2009). Introduction to the R Project for Statistical Computing for use at ITC [Electronic Version], from http://cran.r-project.org/other-docs.html
• Torgo, L. (2003). Data Mining with R: Learning by Case Studies. LIACC-FEP, University of Porto.
• Trosset, M. W. (2009). An introduction to statistical inference and its applications with R. Boca Raton: Chapman & Hall/CRC.
• Vance, A. (2009, January 7). Data Analysts Captivated by R’s Power. New York Times, from http://www.nytimes.com/2009/01/07/technology/business-computing/07program.html
• Vance, A. (2009, January 8). R You Ready for R. New York Times, from http://bits.blogs.nytimes.com/2009/01/08/r-you-ready-for-r/
• Verzani, J. simpleR – Using R for Introductory Statistics.
• Warnes, G. R., & Gorjanc, G. (2008). gdata: Various R programming tools for data manipulation.

Support for R

• Nabble.com
• StackOverflow.com