ACM Programming
Team
Bill Punch
ACM Programming Contest
• One of the premier programming competitions.
• Held every year since 1977
• MSU was the winner that first year!
• In 1992 MSU came in second (of the world competition), second
to Melbourne
• It is a tough competition and requires a lot of practice. You
really have to be "into" this kind of thing to enjoy the effort
that is required
• That's why we are here, to practice
The rules
• Each "team" consists of three members
• teams share a single computer during the contest
• requires some coordination of effort (though less than you might
think)
• Each university can send at most three teams
• Competition is done in two rounds:
• first round is the regional competition
• Our region is ECNA (East Central North America). You can find
them at http://acm.ashland.edu/xxxx where xxxx is the year. No
xxxx means the latest year
• This is a tough region: UoM, Carnegie Mellon, Waterloo, Toronto
more rules
• The top two from each region can go onto the world
competition (held in various lovely places, last year Orlando,
2012 is Warsaw Poland)
• sometimes more than 2 can go from a region. Ours is a pretty
good region
• world competition determines the winner!
Local Competition
• We have to pick teams sometime in September/October.
• selection of teams will be a competition held in the Fall
• Our regional Final will be sometime in late October, probably
at Grand Valley (last year it was Oct 21).
• We will have some competitions during the course of this
semester thanks to Charlie Andrews, using the ACM
programming environment (more on that later).
What we need to do is …
• Get better at learning how to apply algorithms to the
problems that come up.
• Practice, individual practice, is probably the most important so
we will do more of that this semester
You can practice on your own
• http://uva.onlinejudge.org
• There are problems here of varying difficulty which you can
submit and see how well you do
• problems are numbered, we will be working off of these
• you have to register to get onto this site, please do that.
handin
• as a way of keeping track who does what, I have created a
handin site for all of us
• this is prgtem (only allowed 6 letters)
• you should all be registered, at least everyone who came
previously and said they were interested
• I will give out problems each week.
• You submit them to handin before the next session
• Voluntary for those not getting credit, mandatory for those
with credit. Every week, before class
• In the comments of each program, record your time (that is,
keep time as to how long it took you to get a correct
submission to the UVA judge).
It is all about speed
• This is a contest of speed. Comments, organization, OOP, none
of that matters
• Getting the right answer matters!
• What counts as a right answer can be tricky!
• the questions and the examples can look easy, but there are edge
cases that can be difficult, time consuming
• getting your program to run efficiently is often the problem. We
must write efficient code!
Scoring
• Each team gets some number of problems to solve in 5 hours
• 7 – 9 problems, word problems which can be hard to parse
• The team that solves the most problems wins!
• If multiple teams solve the same number of problems, then
how long it took them breaks the tie (short times win)
• Every mis-submission counts as 30 minutes against your time!
• Just remember, the more problems you solve, the better. That
is the winning strategy
• Testing is done by an automatic judge (like UVA) that tests a
broad number of cases
• if you mess up, you can get one of a set of cryptic error messages
saying what went wrong
Languages
• You can use one of 3 languages: C, C++, Java
• We are a C++ shop so we will concentrate on that, but that is
typically not the issue. Knowing the algorithm is the issue
• none the less, familiarity with the language is helpful and we
will talk about that early on.
• If you have never programmed C++ before (or are just
learning), you will have to work some to keep up.
C++ I/O
• All I/O for Acm programming contest problems is assumed to
come from standard in and goes to standard out. No file
manipulation is required
• It is as if the problem were run as follows. Assume the name
of the compiled program is a.out
• ./a.out < input.txt
• output is fed to the console and graded
problem
• Look at Volume1, problem 100
• remember the cin >> someInt will read in an integer from
standard in
• remember that cin.eof() is set to True when cin tries to read
from an empty input
problem
Look at Volume 4, number 483
Couple of things there:
• how to read in the line: getline(cin,line)
• how to parse the line : string streams
• how to reverse the line: reverse iterator is nice