Please see the contest page for links to the contest server on the day. (Subject to change until then.)
The Preliminary Contest has two goals: to be an approachable contest for contestants of all levels, and to select the top teams for Regional Finals, which is the next stage of competition.
See the Regional Finals rules for information about how teams advances from the Preliminary Contest to Regional Finals.
A Note About Divisional Finals vs Preliminary Contest
In 2023, it was decided that we rename the Divisional Finals to the Preliminary Contest. This is intended to better describe the nature of the contest as a qualification contest. Top teams go on to compete in the Regional Finals, which is the next stage.
The contest was originally called the Divisional Finals, because every geographic division would run its own contest and send the winners to the Regional Finals. However, we grouped the entire regional into a single Divisional Final contest since 2015.
Since 2022, there are two levels in the Preliminary Contest: Level A and Level B. Only teams that compete in the Level A contest can advance to the Regional Finals (or be awarded the Boersen prize). Teams must indicate their intent to compete in Level A by using a short form (provided by email) otherwise Level B will be assumed. Teams that have a chance of advancing to the Regional Finals (or winning the Boersen prize) should compete in Level A.
Level B is suitable for most teams as it contains more approachable problems. Level A is suitable for teams with experience and who believe they have a chance to compete for a place at the Regional Finals. The problems in level A are much harder, and may not be approachable for most teams. If you have competed in informatics contests in high school, or if you have placed in the top 20 in an ANZAC, then Level A may be suitable for you. If you are confident your team would solve at least 8 problems from the 2021 Divisional Finals (see the Prog4Fun archive) under contest settings, then Level A may be most appropriate.
Instructions for Site-Coordinators
We urge contestants and site-coordinators to treat the Preliminary Contest as an invigilated exam. Teams are expected to be on site and must follow all the rules. It is your job to ensure the rules are followed! If you cannot have teams on site, please contact the Regional Contest Director
Because teams are allowed only one computer, we ask that site-coordinators print out three copies of the problem set for each team. Of course, teams should under no circumstances see the problem set before the contest starts.
There are two main tools to ensure the rules are followed. The first is to monitor your students carefully. Treat it like an invigilated exam, and get extra help to monitor teams if necessary. The second is to make a custom VM image. This makes it easier to invigilate students, since it is harder for students to access online resources or store material on the machines before the contest. Some tips on creating an image can be found here. Using an image is recommended, but not a requirement.
Rules & Instructions
- Teams must be ICPC eligible to advance to Regional Finals. However, we welcome non-eligible teams to compete as “unofficial” competitors. Unofficial competitors can follow instructions on the contest page on the day.
- Teams must use only one keyboard and computer.
- Teams are allowed to bring as much paper reference material as they like. This includes books and printed notes.
- Teams may use pens, paper, for developing and discussing solutions among themselves.
- Teams should have no internet access other than to the contest server and contest website (this website). Site co-ordinators should ensure this is the case via invigilation or using a custom lab computer image.
- Teams are allowed to print code from their computer. Site co-ordinators should make a best effort to ensure this is supported.
- Teams should not discuss the problems with people outside the team during to the contest, and any questions must be sent through the DOMJudge clarification system.
- Electronic devices (phones, tablets etc) should not be used during the contest. Site co-ordinators should take these devices from contestants for the duration of the contest.
- Teams may not install or store anything on the computers before the contest. Note that this includes any code they wrote during the practice contest. It is not acceptable to give teams access to code they wrote during the practice contest.
- To solve a problem, teams should submit source code through the DOMJudge system written in C, C++, Java or Python. The only feedback teams will receive is “compile error”, “runtime error”, “time limit exceeded”, “wrong answer” or “correct”.
- Teams are ranked by who has solved the most problems, plus the aggregate of the time taken to solve each problem (the time in minutes between the start of the contest and when the correct solution was submitted, plus a 20 minute penalty for each incorrect submission).
- The contest server will evaluate any solution submitted in the five hours from the start of the contest. The scoreboard will stop updating with 1 hour left in the contest, and the full scoreboard will be revealed shortly after the end of the contest.
- Any teams found to be cheating will be removed from the contest server and disqualified.
This is subject to change!
All times are given in Australian Eastern Standard Time (UTC+10):
- 10.45 All competitors on-site
- 11.00-11.30 Practice Contest. Teams who do not have all three contestants on-site during this contest will be disqualified from official participation!
- 11.30-12.00 Break
- 12.00-17.00 Preliminary Contest
- 17.30-18.30 Everyone joins the Zoom link for the scoreboard reveal, award ceremony, and solution explanations
The contest will use DOMjudge to facilitate the contest. The development environment on site is usually a standard install of Debian with standard installed editors/IDEs available. The only programming languages supported at the Regional Finals are C/C++, Java and Python.
Caution About Python
Although you may use Python, a solution in Python is not guaranteed to exist. To be specific, it may be possible that the fastest Python solution may not be fast enough to solve some problems, so use Python at your own risk. It is guaranteed that there is a solution in C++ and Java for each problem.
Note that we now use PyPy3 as our Python runtime. This usually runs much faster than interpreted Python, so generally (almost) all problems can be solved in Python.
Compiler Specifications (Subject to change)
See here for details about the compilers and run-time environments for languages.