# rainfall problem

## Definitionen

Write a program that will read
in integers and output their average. Stop reading
when the value 99999 is input.

Von Elliot Soloway im Text Learning to program = learning to construct mechanisms and explanations (1986) Problem: Read in integers that represent daily rainfall, and print out the average daily rainfall. If the input value of rainfall is less than zero, prompt the user for a new rainfall. When you read in 99999, print out the average of the positive integers that were input other than 99999.

Von Mark Guzdial im Buch Learner-Centered Design of Computing Education (2015) im Text The Challenges of Learning Programming Design a program called rainfall that consumes a list
of numbers representing daily rainfall amounts as en-
tered by a user. The list may contain the number -999
indicating the end of the data of interest. Produce
the average of the non-negative values in the list up to the first -999 (if it shows up). There may be negative numbers other than -999 in the list.

Von Kathi Fisler im Konferenz-Band ICER 2014 im Text The recurring rainfall problem (2014) At Yale University in the 1980s, Elliot Soloway gave the same assignment regularly in his Pascal programming class [Soloway et al. 1983]:

Called “The Rainfall Problem," it became one of the most studied problems in the early years of computing education research.

Von Andy Oram, Greg Wilson im Buch Making Software (2010) im Text Why Is It So Hard to Learn to Program? auf Seite 112*"Write a program that repeatedly reads in positive integers, until it reads the integer 99999. After seeing 99999, it should print out the average.*Called “The Rainfall Problem," it became one of the most studied problems in the early years of computing education research.

In the 1980’s, Elliot Soloway’s group at Yale began capturing all the programs written by computer science students. The students were writing in a programming language called Pascal [154], a notation for writing computer programs that was explicitly invented to be good for teaching students. Student performance on one particular problem intrigued Elliot and his students [294]. […]

Students were expected to write a program that would accept numbers as input from a user at the keyboard. Thee students had to infer what variables would be needed to solve this problem and the combination of things to keep in mind at each step. Each number would be added to a running total of all the numbers read, and a count would be kept of the number of input numbers, so that the average could be printed at the end. If a negative number was input, that should be considered a mistake. The program should not add the number to the total, and the count should not be incremented, but the program should go on to read more numbers. If the input number was 99999, then the program should stop reading numbers, and shouldn’t add that number to the total, and shouldn’t increment the count. Then, print out the average.

This doesn’t seem like an unreasonable task for a Yale Computer Science student. This problem wasn’t computing the next prime number after 1000, or computing the 10,000th digit of pi, or writing a program for Tetris or Angry Birds. However, this was a surprisingly difficult task.

Von Mark Guzdial im Buch Learner-Centered Design of Computing Education (2015) im Text The Challenges of Learning Programming auf Seite 21Students were expected to write a program that would accept numbers as input from a user at the keyboard. Thee students had to infer what variables would be needed to solve this problem and the combination of things to keep in mind at each step. Each number would be added to a running total of all the numbers read, and a count would be kept of the number of input numbers, so that the average could be printed at the end. If a negative number was input, that should be considered a mistake. The program should not add the number to the total, and the count should not be incremented, but the program should go on to read more numbers. If the input number was 99999, then the program should stop reading numbers, and shouldn’t add that number to the total, and shouldn’t increment the count. Then, print out the average.

This doesn’t seem like an unreasonable task for a Yale Computer Science student. This problem wasn’t computing the next prime number after 1000, or computing the 10,000th digit of pi, or writing a program for Tetris or Angry Birds. However, this was a surprisingly difficult task.

- When Elliot’s group gave this task to the first-term computer science students (about week 12 of a 16-week semester), only 14% of the students got it right. Getting the programming language wrong wasn’t the issue - syntax errors were ignored in this analysis. Most often students had trouble not adding in the negative or end numbers, or they didn’t consider troublesome cases, e.g., what if only negative numbers were input?
- Elliot’s group also gave this task to students in their second CS course, in the same 12th week of a 16-week semester. Now, 36% of the students got it right.
- Finally, Elliot’s group gave the task to students in an advanced Systems Programming course, where everyone was a Junior or Senior (3rd or 4th year). 69% of the students got it right. Not 100%, for a problem that seems reasonable to give to first-year students.

## Bemerkungen

Soloway's Rainfall problem has been used in several
studies to assess students' progress in learning to construct programs.

Von Kathi Fisler im Konferenz-Band ICER 2014 im Text The recurring rainfall problem (2014) Soloway identified four key goals within this problem: tak-
ing in input, summing the inputs, computing the average
(which involves counting the inputs), and outputting the
average. Programs that solve this problem must compose
fragments of code that achieve each of these goals. Soloway
proposed this problem in part to study approaches to plan
composition, particularly in novices.

Von Kathi Fisler im Konferenz-Band ICER 2014 im Text The recurring rainfall problem (2014) Over the years, multiple papers have reported on student
performance on Rainfall, sometimes categorizing the errors
that students make. Across prior studies, students typi-
cally solved Rainfall under three common constraints: they
(nearly always) programmed imperatively, they (usually)
obtained the numeric data through keyboard input, and they
(often) had limited prior exposure to data structures, with
the possible exception of arrays.

Von Kathi Fisler im Konferenz-Band ICER 2014 im Text The recurring rainfall problem (2014) ## Verwandte Objeke

Verwandte Begriffe (Cozitation) | notional machine, Programmierenprogramming, Problemproblem, Informatikcomputer science, Lernenlearning |

## Häufig co-zitierte Personen

Kathi

Fisler

Fisler

Raymond

Lister

Lister

Jacqueline L.

Whalley

Whalley

David

Ginat

Ginat

Brian

Dorn

Dorn

Mark

Guzdial

Guzdial

Uri

Wilensky

Wilensky

David

Weintrop

Weintrop

## Statistisches Begriffsnetz

## Zitationsgraph

## 9 Erwähnungen

- Learning to program = learning to construct mechanisms and explanations (Elliot Soloway) (1986)
- ICER 2009 - Proceedings of the Fifth International Workshop on Computing Education Research, ICER 2009, Berkeley, CA, USA, August 10-11, 2009 (Michael J. Clancy, Michael E. Caspersen, Raymond Lister) (2009)
- A closer look at tracing, explaining and code writing skills in the novice programmer (Anne Venables, Grace Tan, Raymond Lister) (2009)

- ICER 2013 - International Computing Education Research Conference, ICER '13, La Jolla, CA, USA, August 12-14, 2013 (Beth Simon, Alison Clear, Quintin I. Cutts) (2013)
- ICER 2014 - International Computing Education Research Conference, ICER 2014, Glasgow, United Kingdom, August 11-13, 2014 (Quintin I. Cutts, Beth Simon, Brian Dorn) (2014)
- Predicting student success using fine grain clicker data (Leo Porter, Daniel Zingaro, Raymond Lister) (2014)
- The recurring rainfall problem (Kathi Fisler) (2014)

- ICER 2015 - Proceedings of the eleventh annual International Conference on International Computing Education Research, ICER 2015, Omaha, NE, USA, August 09 - 13, (Brian Dorn, Judy Sheard, Quintin I. Cutts) (2015)
- Investigating Novice Programmers' Plan Composition Strategies (Francisco Enrique Vicente G. Castro) (2015)

- Learner-Centered Design of Computing Education - Research on Computing for Everyone (Mark Guzdial) (2015)
- Programming Paradigms and Beyond (Shriram Krishnamurthi, Kathi Fisler) (2018)
- ICER 2018 - Proceedings of the 2018 ACM Conference on International Computing Education Research, ICER 2018, Espoo, Finland, August 13-15, 2018 (Lauri Malmi, Ari Korhonen, Robert McCartney, Andrew Petersen) (2018)
- Towards an Analysis of Program Complexity From a Cognitive Perspective (Rodrigo Duran, Juha Sorva, Sofia Leite) (2018)