General rules

Each team participating in CERC consists of three contestants who are eligible to compete in the ICPC World Finals. A representative of the sponsoring institution of higher education, typically a faculty member, must serve as or designate the team coach. The coach certifies the eligibility of contestants and serves as the official point-of-contact with the team prior to and during contest activities. Each team will be allowed to use one provided PC computer.

At least ten problems will be posed. A problem is solved when it is accepted by the judges. Teams are ranked according to the number of solved problems. Teams who solve the same number of problems are ranked by 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 submission of the accepted run plus 20 minutes penalty for every rejected run for that problem regardless of submission time. There is no time consumed for a problem that is unsolved.

Eligibility

The General Rules of the 2024 Regional Competitions, like eligibility, are published on the ICPC website, including Eligibility Decision Diagram. Each team must bring a completed and signed eligibility form at registration.

Keyboards

During the contest, keyboards provided to participants will be of the following type:

Keyboards

Environment

Team hardware

Each team workstation is composed out of laptop with AMD R3 3250U CPU, 8GB RAM and at least 50GB of free memory on NVME drive; which has attached external 1920x1080 monitor, mouse and keyboard. Laptops have lids closed, thus built in monitors are not accessible.

Team software

Participants will work on Linux Debian 12 machines with XFCE desktop environment.

Provided software

C/C++ compilers
  • g++ (version 12.2.0)
  • clang++ (version 14.0.6)
Python3 interpreter
  • python3.11 (version 3.11.2)
  • python3.9 (version 3.9.16)
Note that there will be two versions of Python installed.
There will be alias python3 to python3.9 in .bashrc file.
Java JDK and JRE
  • java
  • javac
Text editors
  • nano
  • vim
  • neovim
  • mcedit
  • joe
Graphical text editors
  • sublime-text
  • thonny
  • mousepad
  • kate
  • gedit
  • gvim
  • emacs
  • scite
Programming environments
  • vs-codium
  • codeblocks
  • geany
Debuggers
  • gdb
  • ddd
  • lldb
Profilers
  • valgrind
  • gprof
Documentation
  • gcc
  • python3
  • java
  • gdb
  • valgrind

Compilation

Language Implementation Command and flags Notes
C gcc 10.2.1 gcc -O2 -Wall -Wshadow -Wextra -x c -lm
C++ g++ 10.2.1 g++ -O2 -Wall -Wshadow -Wextra -x c++ -lm -std=c++17 (or -std=c++20) Contest system allows to choose between C++17 and C++20 standard for submission.
Java javac 11.0.21
  • Compilation: javac -Xlint -J-Xmx{524288}k -encoding UTF-8
  • Execution: java -Xms1m -Xmx{memory_limit}k -Xss{memory_limit}k
Python python 3.9.16 python3 Contest system does a pre-check if the syntax is correct by running py_compile (any error is reported as Compilation Error).

Additional constraints

  • Time limit for compilation: 12 seconds.
  • Memory limit for compilation: 512 MB.
  • Maximum size of the executable: 32 MB.
  • Source code size limit: 100 kB.

Judging hardware

Compilation and execution as described above will take place in a “sandbox” on dedicated judging machines.

Grading machines are using Intel Core i5-6200U @2.30 GHz CPUs.

The sandbox will allocate appropriate chunk of memory, as described in the memory limit section for the submitted problem; the entire program, including its runtime environment, must execute within this memory limit.

For interpreted languages (Java and Python) the runtime environment includes the interpreter (that is, the JVM for Java and the Python interpreter for Python).

The sandbox memory allocation size will be the same for all languages and all contest problems.

Judging software

The contest control system that will be used is Solve 4.

Submissions are evaluated automatically unless something unexpected happens (system crash, errors in test data etc.) in which case Jury reserves right to override the verdicts given by the contest control system.

Submissions can be made via web interface of the contest control system (using web browser). There is no command line tool for submission.

Each team is automatically logged in the contest control system. One should check and make sure that is logged in correctly. The teams are allowed to operate in the contest environment only in the contest hall during contest hours.

Each submitted solution is first compiled using commands listed above. If the solution fails to compile, Compilation Error verdict is issued and the team can access compilation log in the contest environment. Compilation errors do incur time penalties.

If the solution is compiled successfully, it is executed on the set of example tests that are given in the problem statement and on the set of secret tests. The team can access the status of each of the example tests individually and also see the final verdict of grading for the submission on all tests.

The order of example and secret tests is fixed and the same for any execution of the solution for particular problem. The verdict for the submission is either Accepted or the status of the first (example or secret) test for which the submission failed. There is no information about the number of the test case(s) where the submission failed.

The time and memory limits are the same for all the tests for particular problem. Execution time is measured using GNU Time (user+sys time counts). There is additional limit for real time execution (which is always much larger than the time limit of the problem).

List of possible verdicts in the contest control system:

  • accepted - meaning that the solution passed all of the example and secret tests,
  • wrong answer - meaning that the compilation and execution of the solution was without any errors, but the output produced by the solution is incorrect (or presented in invalid format - there is no presentation error status),
  • time limit exceeded - meaning that the execution time of the solution exceeded the limit,
  • runtime error - meaning that execution of the solution produced an error (for example: division by zero, segmentation fault etc.),
  • memory limit exceeded - meaning that the execution of the solution exceeded the memory limit (please note that due to technical reasons it may happend that exceeding the memory limit will be reported as runtime error by the contest system),
  • rule violation - the system recognized that the solution may violate the rules of the contest - Jury will investigate each of these separately and decide how to treat these solutions,
  • system error - there is some problem with checking the correctness of the solution - Jury will check and rejudge the solution as soon as possible.

Any status other than accepted and compilation error incurs additional 20 minutes of time penalty to the problem (counted only for problems that are accepted by the team).

The contest control system allows to print codes with simple syntax markup (through a2ps). Teams can submit codes for printing using web interface (through web browser).

Teams can access the ranking in the contest control system using web interface (through web browser). The ranking shows for each team and each problem the status (accepted/rejected), the number of submissions and penalty time.

Ranking is frozen during last hour of the competition. Submissions made during ranking freeze are visible but their status is not presented.
IIUWr logo Institute of Computer Science
University of Wrocław, Poland