The Rainfall Problem

HollyMinkowski

I have been skimming through some books about teaching programming.
I want to write an introductory book about C and thought I might pick up
some good advice.

I found the following strange item in one of the books.

At Yale University in the 1980s, Elliot Soloway gave the same assignment regularly in his Pascal
programming class [Soloway et al. 1983]:

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 1983 paper from which this formulation of the
problem is taken (other formulations were explored in other papers), the Yale team was
exploring whether having a leave statement (a break in C or Python) improved student
performance on the problem. They gave the problem to three groups of students:

• First-semester CS1 students after learning and using WHILE, REPEAT, and FOR, 3/4 of
the way through the term

• CS2 (second semester of computing coursework, typically a data structures course)
students 3/4 of the way through the term

• Juniors and seniors in a systems programming course

In each class of students, half the students used traditional Pascal and the other half had the
opportunity to use Pascal with an added leave statement. The results, summarized in
Table 7-1, may shock those who have successfully entered a programming career. Only 14%
of the introductory students could solve this problem in raw Pascal? And 30% of the most
advanced students couldn’t solve it either?

The problem requires a relatively complex conditional controlling the loop.

If the input is negative, ignore it but continue to accept input. If the input is positive and not 99999,
add it to the total and increment the count. If the input is 99999, ignore the input and leave the loop.
It’s easy to get an error where negative input or 99999 gets added into the sum.
These results were at Yale University. Could it be that Yale was just really bad at teaching
programming?

I must be missing something here, or the book is in error and has left something out
of this description of the programming challenge!?

This just seems so incredibly trivial.... how could students at Yale fail to create code
to solve this!? Surely Pascal is not such a poor language that it makes writing code to
perform this seemingly simple task extremely difficult.

I'm flabbergasted! This simply cannot be right, there must be important details
missing from the books description of this...anyone here ever heard about this
"Rainfall Problem" before? (and what an odd name to give to this programming task)

Franklin

and what an odd name to give to this programming task

It seems the word problem had to do with recording rainfall and computing average rainfall. The example I saw used decimal numbers and c code.

Heater.

I think there is a lot we don't know about what is going on here.

Depends on what state of mind those students were in before being given the test.
For example, in those days it was common to teach how to plan your program by drawing up a flow chart before you start coding anything. I was a victim of this when first taught programming in a technical school in 1974.

I won't draw the picture here but if you express the problem in a flow chart with simple conditionals you will end up with two of those diamond shaped boxes. One to check "if = 99999", one to check "if < 0".

So when converting that to code it is natural to want to write two separate condition statements. which of course is much easier when you have a "leave" statement.

Trying to it in raw Pascal is just not natural.

Pascal does indeed make this trivial problem harder than languages with a goto:)

Heater.

OK, I have just realized I was replying before my early morning coffee and most of the above is nonsense.
Now I realize I don't understand the problem that the students had with the problem.
Save for the fact that Pascal makes most things harder:)

Leon

I looked it up with Google. It seems to be one of a group of programs that have been subjected to a lot of experimentation in the psychology of programming:

http://www.cl.cam.ac.uk/~afb21/poptasks.html

It's called the "Noah problem" there. I can't remember if Pascal has a break statement, it definitely doesn't have a goto because Wirth didn't like it.

Unknown

Leon wrote: »

I looked it up with Google. It seems to be one of a group of programs that have been subjected to a lot of experimentation in the psychology of programming:

http://www.cl.cam.ac.uk/~afb21/poptasks.html

It's called the "Noah problem" there. I can't remember if Pascal has a break statement, it definitely doesn't have a goto because Wirth didn't like it.

Basic uses goto and return which is considered sloppy programming. It is considered sloppy because code can look like sphagetti and line numbers can change. You don't want an employer to spend hours paying someone to track down a routine in lines and lines of code.

Pascal uses loops so you might need an "if" statement to get out of the loop but there are other tricks that some experienced programmers can teach.

Heater.

In the list linked to by Leon this could also be "The "Average" Program which is described as stopping at 99999. However non of the problems described there mention the ignoring of negative values. Indeed the Noah problem uses -99 as the terminator.

Seems to me a lot of academics have been studying such things for a long time. Meanwhile the real world went ahead an did everything in C anyway:)

homosapien

how could students at Yale fail to create code
to solve this!?

I think you may be putting a little too much emphasis on the fact that this happened at Yale. I remember a certain recent US president who went to Yale and I am quite sure could not complete this simple task.

Bean

I don't see what is so difficult about it ???
I also don't see why Pascal makes it more difficult ???

program rainfall;
{$APPTYPE CONSOLE}
uses
  SysUtils;
Var
  number: longint;
  sum: double;
  count: longint;
begin
  count := 0;
  sum := 0.0;
  repeat
    readln(number);
    if (number > -1) and (number < 99999) then
    begin
      count := count + 1;
      sum := sum + number;
    end
  until number = 99999;
  writeLn(sum / count);
end.

And I didn't even go to Yale...

Bean

vaclav_sal

Holly,
what is wrong with K@R "The C programming language"?
How about "just" updating it to ANSI?
Whatever you do - do not write "C for dummies" and keep it bellow 200 pages.
Vaclav

kwinn

HollyMinkowski wrote: »

I found the following strange item in one of the books.

I must be missing something here, or the book is in error and has left something out
of this description of the programming challenge!?

This just seems so incredibly trivial.... how could students at Yale fail to create code
to solve this!? Surely Pascal is not such a poor language that it makes writing code to
perform this seemingly simple task extremely difficult.

I'm flabbergasted! This simply cannot be right, there must be important details
missing from the books description of this...anyone here ever heard about this
"Rainfall Problem" before? (and what an odd name to give to this programming task)

This being a "word" problem I would really like to see how the problem was presented. I can recall questions from University and High School exams that were so poorly worded that they had less meaning than a politicians promises. One in particular comes to mind. After reading it 3 times, going slower and more carefully each time, I still had no idea what answer the prof was looking for. At the time I wondered if English was his (or her) second or third language.

Phil Pilgrim (PhiPi)

As seasoned programmers, it's easy for us to forget what it was like when first exposed to programming. In my case, I went to a small college that didn't yet have a CS department, but we had limited access to the school's administrative computer (an IBM 1401) one or two nights a week. My Physics prof gave evening classes in Fortran, which I attended. I had never done any programming before and, even though I was good at math, I thought programming was the hardest thing I'd ever been exposed to. It was completely and utterly frustrating to me. Eventually, though, something in my brain clicked, and I "got it."

So I can totally relate to new CS students having difficulty with the "rainfall" problem. Programming requires a mindset that we're not born with, and adopting a completely procedural way of thinking can be a huge and uncomfortable transition.

-Phil

bill190

I think it is a "people problem" in that a computer will do exactly what you tell it. And people new to programming don't think to include every single condition.

Also might be a "dated problem"... In the early 80's, they may have still been using an IBM "batch system" where your program was submitted, then a computer operator coded and ran your program, then you later got the results back via a printout.

These days of course you can try your program on a PC, get instant feedback, see something is wrong, then correct it.

tdlivings

The 1974 time frame was the era of teaching the masses structured programming and early versions of Pascal were designed to
force you to use structures such as repeat until and while do instead of jumping around wildly with goto or even jmp in asm code.
I remember Byte ran articles on implementing the structures using goto, allowed if you were implementing structures.
We all do it now even when writing asm code without even thinkng about it.

Tom

HollyMinkowski

vaclav_sal wrote: »

what is wrong with K@R "The C programming language"?
How about "just" updating it to ANSI?
Whatever you do - do not write "C for dummies" and keep it bellow 200 pages.
Vaclav

K@R is great, although I think Herb Schildt does a better job of writing
introductory C books.

I want to write an easy to follow introductory C course book for starving
artists and aspiring programmers that have played with or just admired the
Arduino boards. Showing these people how to go from a bare Atmega uC
and a handful of parts to a completed project that is programmed using
the WinAVR C compiler is my goal. I feel that it would be better for beginners
to work with the raw chips instead of depending on the Arduino platform...also it
is a lot cheaper to build small projects this way instead of always having
to buy another Arduino board. Much better to spend a few$ initially and
get a USB AVR programmer that can program raw chips instead of buying
a single Arduino board.

There are books that fit this description, but none of them are free. I would
like to make a free one available in PDF and ebook formats and an option to
print up a hard copy at a nominal cost.

If I can turn out something that is not too awful then perhaps a tiny companion
volume about writing asm code for speeding up interrupt routines.

A similar book that substituted the Prop for the AVR might also be nice. It
would be just a bit more intense for a beginner though since setting up the
prop involves an xtal and eeprom chip. Also the available IDE for Prop is not
as nice as AVR Studio with it's simulator. The open source Catalina compiler
is perfectly suitable though. It is a shame that the cost for any project using
the Prop is going to begin at about 10.00USD given the cost of the Prop, the xtal
and the eeprom. It is also overpowered for the sort of simple beginners projects
that I have in mind. In the AVR book I am going to concentrate on the Tiny85
and also the same chips used in the Arduinos.

One nice thing about the Tiny85 is you can run it at 16.5mhz using its internal
calibrated timer and get enough precision to enable connection as a USB
device. This means you can have a USB connected project for just a few measly
dollars....this is just so cool...they cost 1.30 USD each and run at 16mips
without an xtal. They are easily set up to do capacitive touch controls and this
is nice since it eliminates mechanical switches.

Sorry about going on and on about a competitors uC....
I love Prop, I really do.


"C for Starving, Artistic, Cheap Dummies"

localroger

If you have neither leave nor goto, you have to use a state variable or flag to trigger the loop exit. If nobody has ever told you that I can see it not being immediately obvious. I do a lot of work with an embedded device that is event driven and the only way to properly program it is with state machines, but even the people who build it write software that uses multiple and sometimes conflicting state parameters (often physical setpoint values) which result in all kinds of dead states when things don't go as the programmer expected. Once, when I was on vacation in Central America, a problem came up and my employers sent the program to the manufacturer to see if they could fix it. The butcher job they did on my code made it clear that whoever edited it had no idea how it worked, and while the time delay they inserted solved the immediate problem it created several others. And this was done by someone who is probably paid more than me to write software all day long.

erco

"It was my understanding that there would be no math."

schill

I've got to agree with Bean. I don't understand why people think it's so difficult to do this in Pascal.

And anyone who doesn't appreciate Pascal at least at some level must have missed out on the revolution created by Turbo Pascal.

Heater.

Bean,

I also don't see why Pascal makes it more difficult ???

schill

I've got to agree with Bean. I don't understand why people think it's so difficult to do this in Pascal.

I don't really have a downer on Pascal. Apart form the fact that it's syntax is hideous, which is just a personal preference I guess.

I'm just having a bad day with it. Well month actually. You see one of my companies important apps is written it Pascal and it has proved to be a royal pain in the a*** to get it cross compiled for an ARM runnig Ubuntu. The floating point support being the tricky part.

Now we'd like to get it running on an ATMEL920T running a Linux with busybox, this is proving to be beyond me.

If only they had written the thing in C as God intended:)

Dr_Acula

Bean's solution is the purist structured solution. To me, this then translates line for line into C or any of the "non line number" variants of Basic.

I think my very first program was something along the lines of

10 PRINT "HELLO"
20 GOTO 10

and then you have to spend some time unlearning the first instruction that they teach you!

I think the structured programming people have got inside my head and rewired it. I now seek out and destroy any "break", especially ones in "for" loops. I see a break in a loop as a GOTO in disguise! There is always another way - usually using localroger's flags.

kwinn

Dr_Acula wrote: »

Bean's solution is the purist structured solution. To me, this then translates line for line into C or any of the "non line number" variants of Basic.

....................

I think the structured programming people have got inside my head and rewired it. I now seek out and destroy any "break", especially ones in "for" loops. I see a break in a loop as a GOTO in disguise! There is always another way - usually using localroger's flags.

I agree that Beans solution is clean, concise, and easy to understand, pretty much as the concept of structured programming meant it to be. The problem occurs when the purists become the zealots and demand that everything be done exactly such and such a way. Like our spoken languages program languages need to change to accommodate changes in technology and concepts.

I see nothing wrong with having an exit from a loop in a structured language. It can make a program more readable and easier to understand than it would be if you had to search through the code to see where a state variable was set.

localroger

than it would be if you had to search through the code to see where a state variable was set.

If your flag has a meaningful name, or your state variable has maningfully named CONST values, then this is trivial. If your editor is worth anything you do a text search for the name of the variable or the name of the state you're interested in.

This is really the only non-sanity-threatening way to deal with such code.