Get Time
Search | Watch Thread  |  My Post History  |  My Watches  |  User Settings
View: Flat (newest first)  | Threaded  | Tree
Previous Thread  |  Next Thread
3.1. Understanding Marathon Competition Format | Reply
Let me know if I've missed something important for understanding Marathons. I've borrowed a piece about answering questions from Psyho's post here, I think it fits the topic nicely.


TopCoder Marathon Competition has a specific format which is somewhat similar to other long-term on-line contests but still requires some insight. Individual competitions are called Marathon Matches (abbreviated to MMs), or simply Marathons. Prior to competing in one, one has to understand its structure and requirements.


Each MM presents the competitors only one problem. Unlike Algorithm problems, MM problems can not be solved exactly - either because there is no exact solution as such, or it is impossible to find within given time constraints. The task of each MM is to find a solution as close to the optimal one as possible; the quality of the solution is estimated using a certain (problem-specific) scoring system which is described as a part of problem statement. Score depends only on how good your solution performs and never on how many time has passed between reading the statement and submitting the solution.

From technical point of view, MM consists of two phases - Submission and System Testing. Submission phase is the time (a rather long one - usually two weeks, sometimes one or four weeks) to solve and submit the given problem. You can register for the match at any time during Submission phase; the problem statement is available even to unregistered members, so you can decide whether you will take part in a particular match after studying the problem.

After you read the problem statement, figure out a decent way to solve it and code the solution (all done off-line), it's time to submit your solution. You can do two types of submits: Example Test and Full Submission.

Example Test runs your code on a small (usually 10) predefined set of test cases and provides you detailed information on the results: the raw score, the runtime, error messages if the test case crashed and debug output if your solution generates it. This is somewhat similar to testing your SRM solution on examples before submitting it, except that you can't choose the test cases to run. You can do Example Test at most once per 15 minutes.

Full Submission (also referred to as provisional testing) runs your code on a larger (usually 100) predefined set of test cases and provides you only the overall score of this submission, without per-test-case breakout or score. You can do Full Submission at most once per 2 hours.

Current rank-list of the contest is built based on last Full Submissions of all participants. A person is considered to be a participant of the match not if they have registered for it but if they have done Example Test or Full Submission. For some relative scoring systems overall scores of all participants are recalculated after each Full Submission. Example Tests don't affect standings.

After the Submission phase ends, System Testing (or final testing) starts. In this phase the latest Full Submissions of each competitor are tested against even larger set of test cases, and scores on these cases form final standings, used as match results, for rating calculations etc.


Marathon Matches use a format common for long-term contests on hard problems. A few contests similar to typical Marathon tasks are: Al Zimmermann's Programming Contests and Google AI Challenge, and occasional data-mining contests are similar to special Marathon events.

Marathon Matches don't have a tight schedule like SRMs, so they needn't a refined strategy - basically it's just "solve and submit" at your own pace. However, there are some subtle things which should be stressed to avoid common but painful mistakes.

Example Test isn't an actual submit - if you do it but don't do Full Submission, you won't get a final score, so you'll be ranked even lower than people with zero score, with corresponding rating decrease.

Remember about the interval between Full Submissions, and plan last day of competition accordingly. Thus, it is strongly recommended not to postpone your last submission till last hours - a small bug which causes it to crash might leave you without time to resubmit and poor total score. You should leave a few hours for a desperate resubmission, as well as run Example Test before Full Submission - since the intervals between Example Tests and Full Submissions are independent, you'll save a lot of time by checking the validity of your new submission before fully submitting it.

The time management of the match depends heavily on schedule of your daily life during the match. You don't have to stop all activities to do good in a Marathon - sometimes it's enough to get a great idea and a few days to implement it. However, usually Marathon Matches are associated with long-term devotion to solving single problem. It is important to read and re-read problem statement before starting to code, to make sure you understand what you have to do. Play with the visualizer if you prefer visual information over textual one. Submit in the contest only when you're 100% sure that you'll have enough time and inspiration to take part in the match.

To build a strategy for a particular match, you have to answer several questions as early in the match as possible:
- how much time you're willing to spend on this problem?
- what is the purpose of participation - win, increase your rating, win a t-shirt (if there is one for participation or top-something placement), have fun playing with the problem?
- do you need to do any research before approaching the problem?
- how many different approaches you'll try?
- what are fun parts of the problem, and what are possible pitfalls in the scoring?
- what is the variance of the problem and the level of randomness in the results?