Escolar Documentos
Profissional Documentos
Cultura Documentos
Contents
Agenda..................................................................................................................................................2 Programming Contest Rules.................................................................................................................3 Resources..............................................................................................................................................4 Anatomy of a problem..........................................................................................................................5 Necessary skills.................................................................................................................................... 6 Input and Output...................................................................................................................................6 Data Structures and Algorithms............................................................................................................7 Teamwork............................................................................................................................................. 8 Testing and Debugging......................................................................................................................... 8 Common Mistakes in Online and Real-time Contests......................................................................... 9 Teamwork in Programming Contests: 3 * 1 = 4 ................................................................................14
Agenda
Time Topic 9:00 9:05 9:30 Welcome and overview. Introductions What's CS, why is it cool, and how programming contests make it cooler. Programming Competition overview Basic rules Anatomy of a problem Programming tools Theory: Programming competition skills and teaching the skills Data Structures Algorithms Input and Output Teamwork Testing and debugging How to write a problem Location B016 B016 B016 Materials Agenda Presentation Handout with rules Links to get more sample problems. Handouts
9:45
B016
10:15 Break: Move to ARC cluster 10:30 Practical Session with PC2: Input/output problem Basic algorithm problem Testing problem 11:00 Mini Competition Team up with members of CMU programming team. 11:45 Final Discussion 12:00 Lunch ARC 3 problems
ARC
3 problems
ARC ARC
Regulations
Contestants are not to converse with anyone except members of their team and organizers of the contest. A team may be disqualified for any activity that jeopardizes the contest such as dislodging extension cords, unauthorized modification of contest materials, or distracting behavior. A team may have up to 3 students per team. Each team may use only one computer, keyboard, and monitor. Sample test data will be provided for each problem. The team will run their solution. If they deem it correct, they can submit it to the judges. The judges will review the submitted program and give feedback indicating the solution is accepted or rejected. The test data files used by the judges might be different than the ones given to the teams. Each problem is solved when it is accepted by the judges. Each team may submit a clarification request to the judges. If the judges agree that there is an ambiguity or an error exists, a clarification will be issued to all participating teams.
Evaluation Criteria
Teams are ranked according to the most problems solved. For the purposes of awards, teams who solve the same number of problems are ranked by least total time. The total time is the sum of the time consumed for each problem solved. The time consumed for a solved problem is the time elapsed from the beginning of the contest to the submittal of the accepted solution plus 10 penalty minutes for every rejected solution for that problem regardless of submittal time. There is no time consumed for a problem that is not solved.
Resources
Java Programming Environment
DrJava
http://www.drjava.org
Eclipse
http://www.eclipse.org/
Netbeans
http://www.netbeans.org
Sample Problems
The following link is to IBM's online resource for high school programming contests. http://www-304.ibm.com/jct09002c/university/students/highschool This site includes sample problems, teaching resources, tutorials for students, and instructions for running and judging contests.
Anatomy of a problem
Almost every problem has five parts: the story, input specification, algorithm, output specification, and test data.
Story
The story usually includes some fictitious situation where someone has a problem and needs a computer program to solve it. Sometimes the story can be misleading. It might make the problem seem harder than it really is, so students need to be able to determine the fundamental problem posed by the story. The story is also a way to get students to think about real world problems that can be solved with computer science. The subtle goal is to get students beyond the software syntax to see the power and versatility of computer science.
Input Specification
This contains a detailed description of the input format. A good input specification for a problem gives exactly enough detail for the problem. For example if a program should be able to accept both integer and floating point input that is strictly positive, then the specification could say input will be a positive number.
Algorithm
The students should be able to clearly understand what the program should do. The description should give exactly enough detail to understand the problem while requiring the student to identify the challenging test cases. Students should know common mathematical formulas, so common formulas should usually be omitted.
Output Specification
The output specification should be more detailed than the input specification. The teams need to think about all the possible crazy input the judges might throw at them, but they should always know the exact format for the answer.
Test Data
The given test data usually includes some simple examples. As a general rule the judges will not include tricky examples in the sample input/output; they want to save those test cases for judging the competition. Students should be able to identify the tough test cases for a given problem.
Necessary skills
To do well in a programming contest the students should know how to Handle various types of input and output Implement basic data structures and algorithms Work together efficiently Test and debug their solution.
Selected Methods: next() - reads next token and returns a String. nextInt() - returns the next token as an integer value. nextDouble() - returns the next token as a double value. nextLine() - reads to the next new line and returns a String. hasNext() - returns true if there is at least one more token. Notes:
Be as specific as is necessary when writing the input specification for a problem. Will the input be integers, floating point numbers? If the specification if vague then the solution should be able to handle all permissible input. When writing the specification, or when looking at a problem think about Integers or floating point? Positive, zero, negative input? What's the largest and smallest possible input value? What's the maximal or minimal length for a string?
Output
System.out.print(String)//outputsStringtotheconsolewithoutanewline System.out.println(String)//outputsStringwithanewline
Teamwork
Problem:
How do you use 3 people and one keyboard to solve as many problems as possible? There are many useful ideas in the attached article: Teamwork in Programming Contests: 3 * 1 = 4 by Fabian Ernst, Jeroen Moelands, and Seppo Pieterse Read & Classify Problem Formulate Solution Code Solution Test Solution Debug Solution
+1
Every problem requires time at the computer. The students should try to solve as much of the problem as possible before typing (except when solving the first problem). This reduces congestion at the keyboard. Students that can work separately can usually solve more problems.
+1 +1 +1
Correct
Your program must read input from a file or standard input according to the specification of the contest question. Judges will test your program with their secret input. If your program's output matches the judges' output you will be judged correct.
Incorrect output
If the output of your program does not match what the judges expect, you will get an incorrect output notification. Generally, incorrect output occurs because you have either misunderstood the problem, missed a trick in the question, didn't check the extreme conditions or simply are not experienced enough to solve the problem. Problems often contain tricks that are missed by not reading the problem statement very carefully.
10
No output
Your program does not produce an output. Generally this occurs because of a misinterpretation of the input format, or file. For example, there might be a mixup in the input filename e.g., the judge is giving input from "a.in," but your program is reading input from "b.in." It is also possible that the path specified in your program for the input file is incorrect. The input file is in most cases in the current directory. Errors often occurs because of poor variable type selection or because a runtime error has occurred, but the judge failed to detect it.
Presentation error
Presentation error's occur when your program produces correct output for the judges' secret data but does not produce it in the correct format. Presentation error is discussed in detail later in this article.
Runtime error
This error indicates that your program performs an illegal operation when run on judges' input. Some illegal operations include invalid memory references such as accessing outside an array boundary. There are also a number of common mathematical errors such as divide by zero error, overflow or domain error.
Line intersection. Line segment intersection. Line and line segment intersection. Convex hull. If a point is within a polygon. From a large number of points what is the number of maximum points on a single line. Closest pair problem. Given a set of points you have to find out the closest two points between them. Try to learn how to use C's built-in qsort() function to sort integers and records. Area of a polygon (convex or concave). Center-of-gravity of a polygon (convex or concave). Minimal circle, a circle with the minimum radius that can include the coordinates for a given number of points. Minimal sphere. Whether a rectangle fits in another rectangle even with rotation. Identify where two circles intersect. If they don't, determine whether one circle is inside another or if they are far away. Line clipping algorithms against a rectangle, circle, or ellipse.
Here, ERROR is a very small floating-point value like 1e-15. Actually, 1e-15 is the default value that the judge solution writers normally use. This value may change if the precision is specified in the problem statement.
12
Presentation error
Presentation errors are neither caused by algorithmic nor logical mistakes. There is a difference between the presentation error of online judges and that of live judges. The latter are able to detect mistakes such as misspellings, extra words, extra spaces, etc., and differentiate them from algorithmic errors, such as wrong cost, wrong decisions, etc. These mistakes are the presentation errors as graded by the human judges. On the other hand, online judges in most cases compare the judge output and the contestant output with the help of a file compare program so that even spelling mistakes can cause a "wrong answer." Generally, when the file compare program finds extra new lines, these are considered to be presentation error. Human judges, though, do not typically detect these mistakes. But now computers are becoming more powerful, larger judge inputs are being used and larger output files are being generated. In live contests, special judge programs are being used that can detect presentation errors, multiple correct solutions, etc. We are advancing towards better judging methods and better programming skills. The recent statistics of the ACM shows that participation in the ACM International Collegiate Programming Contest is increasing dramatically, and in the near future the competition in programming contests will be more intense [5]. So the improvement of the judging system is almost a necessity.
References
1Astrachan, O., V. Khera, and D. Kotz. The Internet Programming Contest: A Report and Philosophy 2Chowdhury, R. A., and S. Manzoor. Orientation: National Computer Programming Contest 2000, Bangladesh National Programming Contest, 2000. 3Ernst, F., J. Moelands, and S. Pieterse. Teamwork in Programming Contests: 3 * 1 = 4, Crossroads, 3.2. 4Kaykobad, M. Bangladeshi Students in the ACM ICPC and World Championships, Computer Weekly. 5Poucher, W. B. ACM-ICPC 2001, RCD Remarks, RCD Meeting of World Finals 2001. 6Verhoeff, T. Guidelines for Producing a Programming-Contest Problem Set: http://wwwpa.win.tue.nl/wstomv/publications/guidelines.html
13
Introduction
Every year since 1977, the ACM has organized the ACM International Collegiate Programming Contest. This contest, which consists of a regional qualifying contest and the Finals, provides college students with the opportunity to demonstrate and sharpen their programming skills. During this contest, teams consisting of three students and one computer are to solve as many of the given problems as possible within 5 hours. The team with the most problems solved wins, where ``solved'' means producing the right outputs for a set of (secret) test inputs. Though the individual skills of the team members are important, in order to be a top team it is necessary to make use of synergy within the team. As participants in the 1995 Contest Finals (two of us also participated in the 1994 Finals), we have given a lot of thought to strategy and teamwork. In this article we summarize our observations from various contests, and we hope that if you ever participate in this contest (or any other) that this information will be valuable to you.
Knowledge of standard algorithms and the ability to find an appropriate algorithm for every problem in the set; Ability to code an algorithm into a working program; and Having a strategy of cooperation with your teammates. Team strategy will be the core discussion of this article. Nevertheless, there are some important considerations for improving your individual skills.
After analyzing previous contest programming problems, we noticed that the same kind of problems occurred over and over again. They can be classified into five main categories: 1. Search problems. These involve checking a large number of situations in order to find the best way or the number of ways in which something can be done. The difficulty is often the imposed execution time limit, so you should pay attention to the complexity of your algorithm. 2. Graph problems. The problems have a special structure so they can be represented as a 14
graph-theoretical problem for which standard algorithms are available. 3. Geometrical problems. These involve geometrical shapes, lines, and angles. 4. Trivial problems. The choice of appropriate algorithm is clear, but these usually take quite a long time to program carefully. 5. Non-standard problems. For the first three categories, standard algorithms are well documented in the literature, and you should program these algorithms beforehand and take the listings with you to the contest. In this way, you can avoid making the same (small) mistakes repeatedly and you can concentrate on the difficult aspects of the problem. Another angle of practice is efficient programming. This does not mean type as fast as you can and subsequently spend a lot of time debugging. Instead, think carefully about the problem and all the cases which might occur. Then program your algorithm, and take the time to ensure that you get it right the first time with a minimum amount of debugging, since debugging usually takes a lot of valuable time. To become a team, it is important that you play a lot of training contests under circumstances which are as close to the real contest as possible: Five hours, one computer, a new set of problems each time, and a jury to judge your programs.
15
Other Considerations
Since the contest final standings are based on the number of problems correctly solved, and (in the case of ties) on the sum of elapsed time for each problem, a team should adopt a strategy that maximizes the number of solved problems at the end of the five hours, and view the total elapsed time as a secondary objective. In every contest there are some teams in the ``top six'' after three hours, that are not even in the ``top ten'' after the total five hours. The reverse also occurs. A long term strategy is therefore important: Try to optimize the 15 man hours and 5 hours of computer time, and do not worry about your total time or how quickly you solve the first two problems. To optimize this scarce time, try to finish all problems that you start. A 99% solved problem gives you no points. Analyze the problem set carefully at the beginning (for example, by using a ``thinktank'' approach) to avoid spending more time than absolutely necessary on a problem that you will not finish anyway, and to avoid misjudging an easy problem as being too difficult. You need a good notion about the true difficulty of the various problems as this is the only way to be sure that you pick exactly those which you can finish within five hours. Since you never have perfect information, you have to take risks. If you follow a risky strategy by choosing to tackle a large number of problems, you might end up in the bottom half of the score list when each is only 90% solved, or you might be the winner in the end. On the other hand, choosing a smaller number of problems has the risk that you have solved them correctly after four and a half hours, but the remaining time is too short to start and finish a new problem, thus wasting ten percent of the valuable contest time. Time management should play a role in your strategy. If you are going to work on a large problem, start with it immediately or you will not finish it. Although this sounds trivial, there are a lot of teams which start out with the small problems, finish them quickly, and end up with only three problems solved because they did not finish the larger ones. In our opinion, debugging should have the highest priority at the terminal after 3.5 hours. When you start with a new problem that late in a contest, the terminal will become a bottleneck for the rest of the contest. Of course terminal management is crucial. Though most programs are quite small (usually not exceeding one hundred lines of code), the terminal is often a bottleneck: Everyone wants to use it at the same time. How can this be avoided? The first thing to remember is: Use the chair in front of the terminal only for typing, not for thinking. Write your program on paper, down to the last semicolon. In this way you usually have a much better overview, and you have the time to consider all possible exceptions without someone breathing down your neck, longing for the terminal. Once you have finished writing, typing will take no more than 15 minutes. Though you should avoid debugging (this IS possible if you plan the program carefully on paper), when you really have to do it you should do it in a similar way: Collect as much data as possible from your program, print it out and analyze it on paper together with your code listing. Real- time tracing is THE ULTIMATE SIN.
16
Advantages are that little practice is needed. Total elapsed time will be minimal, since the easiest problems are solved first. However, there are also severe disadvantages: Since the easiest problems usually have the same level of difficulty, everyone will finish their problem at about the same time. Thus the terminal will not be used for the first hour, since everyone is working on a problem on paper, and remains a bottleneck thereafter. Furthermore, only the easy problems will be solved, because no time will be left for the hard ones. The conclusion is that, provided your programming skills are adequate, you will solve about three or four problems as a team. This will bring you, with a good total elapsed time, into the top ten, but probably not into the top three.
2. Terminal Man
In the terminal man (TM) strategy, only one of the team members, the T, uses the computer. The other two team members analyze the problem set, write down the algorithms and the (key parts) of the code, while the T makes the necessary I/O-routines. After an algorithm is finished, the T starts typing and, if necessary, does some simple debugging. If the bug is difficult to find, the original author of the algorithm helps the T to find it. Advantages of this strategy are that the terminal is not a bottleneck anymore, and the task of solving a problem is split over people who specialized in the different parts of the problem solving process. A disadvantage is that no optimal use is made of the capacities of the T, who is mainly a kind of secretary. If you only one of you is familiar with the programming environment, this might be a good strategy. You can write a lot of programs in the first part of the contest when your brain is still fresh, since the typing and debugging is done by someone else. It depends strongly on the composition of your team if this strategy is suitable for you.
3. Think Tank
The strategy we followed during the preparation and playing of the Contest Finals of 1995 made use of the above-mentioned ``think tank'' (TT). We felt that choosing and analyzing the problems was such a crucial task in the early stages of a contest that it should not be left to a single person. The two team members who are the best problem analyzers form the TT and start reading the problems. Meanwhile the third member, the ``programmer'', will type in some useful standard subroutines and all the test data, which are checked carefully. After 15 minutes, the TT discusses the problems briefly and picks the one most suitable for the third team member. After explaining the key idea to the programmer, they can start working on it. Then the TT discusses all problems thoroughly, and puts the main ideas of the algorithm down on paper. We found out that two people examining hard problems often lead to creative solutions. After one hour the TT had a good overview over the problem set, and all algorithms were found. The next decision is how many problems you want to solve. The easiest or shortest problems are handled by the programmer, while the TT divides the other ones among themselves. The terminal is only used for typing in code from paper or gathering information from a buggy program. If a program is rejected by the jury and no bug can be found, it is put aside until the last hour of the contest. In principle, after three and a half hours no more new code is typed. The team will briefly discuss the situation, and a plan is made for how to solve the problems which have yet to be debugged. Some advantages of this approach are that you will almost always tackle the programs which have a reasonable chance of being solved correctly, and the hard problems can be solved because the TT will start working on them in an early stage of the contest. A clear disadvantage is that you will have a relatively slow start and your total time is not optimal. So to win, you need to solve one problem more than the other teams. We feel that for a team consisting of partners with about equal 17
skills, this strategy will help you solve as many problems as possible.
Concluding Remarks
In this article we have recorded some of our experiences with programming contest strategies. Though these strategies are very dependent on the individual qualities of the team members, the concepts apply equally to all teams. We hope that the information contained in this article will be useful to you, should you ever want to participate in the ACM Programming Contest (we definitely recommend it!). More information about the contest can be found on http://www.acm.org/~contest. A report of our experiences at the Contest Finals, including more considerations on team strategy, can be found at http://www.cs.vu.nl/~acmteam/ .
18