October 1960 - Vol. 3 No. 10
Features
Automatic graders for programming classes
Fifteen months ago the first version of an “automatic grader” was tried with a group of twenty students taking a formal course in programming. The first group of twenty programs took only five minutes on the computer (an IBM 650). With such a satisfactory beginning, the grader was then used for the entire course with this group of students and have been used at Rensselaer ever since. For all exercises, the average time spent on the computer has run from half a minute to a minute for each student. In general only an eighth as much computer time is required when the grader is used as is required when each student is expected to run his own program, probably less than a third as much staff time, and considerably less student time. The grader easily justifies itself on economic grounds. It accomplishes more than savings in time and money; it makes possible the teaching of programming to large numbers of students. This spring we had 80 students taking a full semester course in programming; over 120 are expected next spring. We could not accommodate such numbers without the use of the grader. Even though the grader makes the teaching of programming to large numbers of students possible and economically feasible, a most serious question remains, how well did the students learn? After fifteen months, our experience leads us to believe that students learn programming not only as well but probably better than they did under the method we did use—laboratory groups of four or five students. They are not as skilled in machine operation, however, since they get only a brief introduction to it late in the course. After learning programming, very little time is needed for each student to become at least an adequate machine operator. Students seem to like the grader and are not reluctant to suggest improvements!
Do it by the numbers—digital shorthand
Present communications systems transmit single characters in groups of coded pulses between simple terminal equipments. Since English words form only a sparse set of all possible alphabetic combinations, present methods are inefficient when computer systems are substituted for these terminals. Using numeric representations of entire words or common phrases (rather than character-by-character representations) requires approximately one-third of present transmission time. This saving is reflected in overall costs. Other benefits accrue in code and language translation schemes. Provision is made for transmission of purely numeric and/or binary streams, and for single character-transmission of non-dictionary words such as the names of people of places.
Comments on a technique for counting ones
Peter Wegner [1] describes a short 704 SAP program that is faster than the standard technique. The expected number of loops—of five instructions each—for a word half of whose bits are ones, is 18 in this program.
Some thoughts on parallel processing
In the past two years or so I have seen a number of papers and heard a number of talks describing the characteristics of (and the wonders inherent in) certain computers like Gamma 60, LARC, H-800, STRETCH, and others. Of course, all these machines share a capacity for parallel asynchronous multiple processing. Now this is a truly marvelous property, especially from the point of view of the common variety of “my-job's-on-the-machine-keep-your-cotton-pickin'-hands-off” programmer.
Evaluating numbers expressed as strings of English words
Integer numbers can be expressed in English by a series of words such as “one hundred thirty three million two hundred four.” The process indicated by the accompanying flowchart evaluates numbers represented by such a string. To include words up to “billion” requires four terms “Sumi.” The multiplications can be done by shifting on a decimal machine.
