TEACHING ADVANCED PROBLEM SOLVING: IMPLICATIONS FOR THE CS CURRICULUM John Paxton,
[email protected] Brendan Mumey,
[email protected] Computer Science Department Montana State University - Bozeman Bozeman, MT 59717
ABSTRACT In this paper, we discuss our experiences with an advanced problem solving seminar and ACM programming contests. These are both activities that require teams of students to solve problems that are more challenging than those typically encountered in computer science courses. After presenting some effective and not-so-effective strategies in these environments, we conclude the paper by taking our observations and applying them to the computer science curriculum as a whole. By casting a spotlight on the curriculum from this more advanced setting, we are able to identify some weaknesses that must be addressed. Because our curriculum is a fairly typical one, we hope that this analysis might help other universities and colleges reflect upon their curricula as well. SEMINAR OVERVIEW In the fall semester of 1999, we taught a one credit seminar on the topic of “Advanced Problem Solving” [6]. 15 students enrolled in the course and were organized into five teams of three students each. The goals of the course were to (1) help students become better problem solvers [5,8] and to (2) help students to better compete in local and regional programming contests. Each week, the class meeting was divided into two segments. First, student teams presented conceptual solutions to a problem that was passed out as a ``thought problem'' the preceding week. For example, if the theme of the previous week was dynamic programming, the “thought problem” would be a problem that required dynamic programming to be solved elegantly. Student teams presented their ideas and the class as a whole provided feedback. At the end of the class period, the students were given another problem on this same theme. For this problem, students had one week to implement a solution using a programming language of their choice. JCSC 16, 2 (May 2001) © 2001 by the Consortium for Computing in Small Colleges
51
JCSC 16, 2 (January 2001)
In the second segment of the class meeting, one of the instructors introduced a new problem solving technique (such as the greedy approach) and demonstrated it on a sample problem. When the technique was demonstrated in the context of a program, Java was used as the programming language. This problem solving technique would form the basis for the “thought problem” (described above) that would be passed out to be discussed the following week. In the course of the semester, some of the problem solving techniques covered included: C
Dynamic Programming.
C
The Greedy Method.
C
Geometric Techniques. For example, how to determine efficiently if any three points in a set are colinear.
C
Manipulating Strings. For example, how to do simple keyword matches in a World Wide Web search.
C
Representing Large Numbers. For example, finding and printing the exact representation of 100!
C
Backtracking.
C
Choosing Data Structures [1,3]. For example, using nonstandard representations of binary trees to solve a problem more effectively.
The students were graded exclusively on their ability to implement solutions to the programming problems. For each assignment, their submission received a 0 (no attempt), a 1 (a non-working attempt), a 2 (a solution that worked except for special cases), or a 3 (a perfect solution). Thus, a premium was placed on the ability of a team to find a correct solution under any constraints (such as time or space) that were imposed. In addition, students were required to participate in a local programming contest, but no grade was attached to how they performed there. FACULTY EVALUATION OF SEMINAR Overall, we (the instructors) assess the seminar to be a success. There were some aspects of the seminar that were particularly pleasing and others where room for improvement remains. In the next two paragraphs, first the strengths and then the weaknesses of the seminar will be discussed. There were several successful aspects of the seminar. First, many of the problem solving techniques were new to the students. For example, most students had never before encountered strategies for dealing with numbers that are too big to represented by the programming language built-in data types. Second, the seminar focused on problems that were selected from previous local, regional, and international programming contests [4]. These problems typically have a practical orientation and are consequently quite interesting to the students. By looking at problem solving techniques in the context of “real” problems, we found 52
CCSC: Northwestern Conference
that students were more motivated than they might have otherwise been. Third, it worked well to spend two full weeks on each problem solving technique. By introducing the technique with one example during lecture A, then having students look at a ``thought problem'' during lecture B, and assigning a third programming problem due at lecture C, students were better able to absorb the technique than if it had been covered during one class meeting. Despite the successes of the course, there were also several areas where improvement is possible. First, although each team consisted of three students, it seemed that typically only one or at most two of the students on a team would actively participate in the programming assignments. In the future, we need to either decrease the team size to two or install new mechanisms into the class to make sure that all students are involved. Second, the seminar could easily be turned into a two credit course. With a challenging program (albeit one that was typically less than 100 lines of code) due each week, students were having to work harder than normal for one credit. Third, although the teams were consistently able to submit programming solutions, they often neglected to spend the time necessary on the “thought problems” to get the feedback necessary on whether or not they truly understood a problem solving technique. To counter this, we should either have made the “thought problem” a graded portion of the class or made the class worth two credits. Fourth and finally, testing of programs on boundary cases should have been more highly emphasized. On many assignments, it was apparent that students had spent quite a bit of time working out the solution, but only checked the program on the sample data file. STUDENT EVALUATION OF SEMINAR Overall, the students enjoyed the seminar and found it to be a fun, worthwhile experience. Some constructive criticism that came from the students included: C
The class had too much work for a one credit seminar. Since the material is fun and worthwhile, change the seminar to two credits.
C
The problem solving techniques should be ordered from easiest to hardest as the semester progresses. One possible ordering would be to do string algorithms first, followed by selecting the correct data structure, followed by representing large numbers, followed by the greedy method, followed by backtracking, followed by dynamic programming, and finishing with geometric techniques.
C
More time is needed to help identify what type of problem solving technique will be useful for a given problem.
C
More time should be spent on learning to recognize the difficulty of a problem. This is particularly useful in a programming contest environment.
C
Ensure that each team has a mix of upper division and lower division students. Teams consisting of only lower division students are at a distinct disadvantage, both in the homework problems and in the programming contest.
53
JCSC 16, 2 (January 2001)
PROGRAMMING CONTESTS As a non-graded part of the advanced problem solving seminar, students were required to compete in a local programming contest. In this contest, teams of three students used one PC to see how many problems they could collectively program solutions for in a five hour time period. The two winning teams moved on to the ACM regional programming contest where the format was again the same. Because the advanced problem solving seminar emphasized problem solving techniques and problems that frequently arise in these contest environments, it was our hope that the students enrolled in the seminar would do especially well. Although one of the teams of students finished in the top two teams, the other teams fared not as well. In the next paragraph, we will describe what the effective teams managed to do. Teams that were not as effective failed on one or more of these same points. The teams of students who succeeded at both the local and the regional level shared many common attributes. C
The teams were good at assessing the difficulty of the problems and solved the easiest ones first.
C
The teams brought in and could effectively use resources such as programming language references, algorithm and data structure references, and mathematical references.
C
The teams were able to multitask effectively. One team member might use the PC, while a second member looked on giving suggestions and the third member designed a solution to another problem.
C
The team had at least one very strong problem solver. Oftentimes, this student had a strong math or physics background.
C
The team had at least one very good coder.
C
The team had practiced as a team in advance. By doing this, the dynamics and strategies of the team did not need to be worked out ``on the fly''.
C
All coders on the team were familiar with the programming contest environment (such as IBM's VisualAge).
C
The team read the instructions carefully. Oftentimes, a problem would require a particular input data file or a particular output file capitalization requirement.
C
The team was good at constructing test data that would test the program's boundary conditions. Since the judge's data often tested boundary conditions, this would give the team a better chance to have a submission work correctly.
CURRICULUM IMPLICATIONS Having taught an advanced problem solving seminar and having been involved in several programming contests, there are several general observations we can make about how the
54
CCSC: Northwestern Conference
computer science curriculum at our university can be improved. Because our curriculum is fairly standard, we feel that many of these observations might be useful at other universities as well. The advanced problem solving seminar illustrated that students need to bolster many software engineering skills. First, students need to become better at working in teams [2]. When problems are conceptually difficult, it might require more than one person to develop a solution. Second, students need to become better at testing. In both the seminar and at the programming contest, most students did not fully appreciate how to develop suitable test sets. Third, students need to become more comfortable working with a deadline. Whether the situation is a programming contest, a programming assignment, or a product ship date, deadlines add a certain amount of stress to a situation. Students must learn to be able to perform under duress. Fourth, students need to become more comfortable using IDEs (integrated development environments) such as Microsoft's J++ 6.0. We noticed that students often did not use useful features such as online help facilities or debuggers. All four of these skills can be stressed in a software engineering course, although some of them (such as using an IDE) are applicable throughout the curriculum. In terms of courses that cover algorithms and data structures [9], we can also make several observations. First, our curriculum needs to feature tougher problems. Many of the students in the seminar commented that the majority of their programming careers have been spent on problems where the solution is “obvious” and the project time is mostly spent hammering out small details. While learning about these small details is certainly important to becoming a good programmer, it would also be helpful to give students more experience with problems where the solution is not “obvious” from the word go. Second, when the problem is harder, students are at a loss as to how to approach it. Even though our local programming contest featured seven problems that were all akin to problem types that we had covered in the advanced problem solving seminar, students taking the class were typically only able to figure out which approach to use for one or two of these problems. Thus, determining the problem solving technique [7] for a given problem should also be better stressed throughout our curriculum. Finally, the flexibility of being able to choose from competing languages in the seminar points out the need for students to be able to intelligently select the correct language for the problem. Students typically select the language they are most comfortable with, even when another programming language would enable a problem to be solved more easily. Perhaps instructors should stress the strengths and weaknesses of the languages that are being used more, especially in upper division courses where students have become proficient in more than one language. Thus, by teaching a one credit advanced problem solving seminar and observing how students fare in programming contests, we have identified several areas within our computer science curriculum that can be improved. We hope that some of these same observations might provide some impetus for change in other curricula as well.
55
JCSC 16, 2 (January 2001)
REFERENCES 1.
Aho, Hopcroft, Ullman., Data Structures and Algorithms. Addison-Wesley Publishing. 1983.
2.
Chase, & Okie, E. Combining Cooperative Learning and Peer Instruction in Introductory Computer Science. SIGCSE Bulletin, Volume 32, Number 1, pp. 372-376, 2000.
3.
Cormen, Leiserson, Rivest. Introduction to Algorithms. McGraw Hill Publishing, 1990.
4.
Karrels, E. Ed's Programming Contest Problem Archive, www.karrels.org/Ed/ACM/, 1999.
5.
Levitin, A., Do We Teach the Right Algorithm Design Techniques? SIGCSE Bulletin, Volume 31, Number 1, pp. 179-183, 1999.
6.
Paxton, J. & Mumey, B. Advanced Problem Solving Seminar, http://www.cs.montana.edu/mumey/courses/F1999/cs400/default.htm, December, 1999.
7.
Polya, G., How to Solve It: A New Aspect of Mathematical Method. Princeton University Press, 1972.
8.
Preiss, B., Design Patterns for the Data Structures and Algorithms Course. SIGCSE Bulletin, Volume 31, Number 1, pp. 95-99, 1999.
9.
Proulx, V. Programming Patterns and Design Patterns in the Introductory Computer Science Course. SIGCSE Bulletin, Volume 32, Number 1, pp. 80-84, 2000.
56
