HKOI Programming HKOI Training Team (Intermediate) Alan, Tam Siu Lung Unu, Tse Chi Yung

What you should learn from this lesson How to solve a problem How to code faster How to test your program How to score more

Today’s flow Competition Rules Problem Solving Coding Testing Tricks

Competition Rules The winner is determined by – Fastest program? – Amount of time used in coding? – Number of tasks solved? – Highest score

Scoring Black-box Testing Marks will be given if a program passes a certain test case A test case is passed if the output – matches the expected one, or – satisfies certain criteria No referral to source code

The “OI” Programming Process Choosing a problem Reading the problem Thinking Coding Testing Finalizing the program

Reading the problem Usually, a task consists of – Title – Problem Description – Constraints – Input/Output Specification – Sample Input/Output – Scoring

Reading the problem Constraints – Range of variables – Execution time NEVER make assumptions yourself – Ask whenever you are confused Read EVERY word Make sure you understand before going on

Thinking Classify the problem – Graph? Mathematics? Data Processing? … Compare with some past problems – Any similarity? For complex problems, divide the problem into smaller sub-problems

Thinking Draw diagrams Consider special cases Is the problem too simple? – Be suspicious, you may have overlooked something Still no idea? Give it up… Try again later

Designing the solution Some points to consider – Execution Time (Time Complexity) – Amount of memory used (Space Complexity) – How to store data? (Data Structure) – Difficulty in coding

Coding Coding is just a small part in the competition Less coding time means more time for thinking (which is more important) FYI, usually Unu completes a program in 15 minutes How to perform problem reduction faster?

Characteristics of OI programs Simple Input/Output Assumption: Data input format always matches specification Short programs (usually < 100 lines)

Common practices in OI-coding No comments needed Short variable names (usually 1-2 chars) Less procedures / functions Use of break, continue and goto Hardcoding (Not recommended)

Common practices in OI-coding Use a slightly larger array than needed Pascal users: use longint instead of integer Avoid real numbers (sometimes not possible) Avoid long and complex expressions Save and Compile frequently

Testing Sample Input/Output “A problem has sample output for two reasons: 1. To make you understand what the correct output format is 2. To make you believe that your incorrect solution has solved the problem correctly ”

Testing Create some simple input yourself (by hand) Boundary cases “Large” input – Test for execution time and integer overflow Tricky cases

Debugging Print values of important variables to screen and/or files Print messages to screen and/or files Use debugger – FreePascal IDE debugger – GDB

Finalizing Check I/O filename Check output format – Any trailing spaces? Correct source/executable name? Is the executable updated?

Tricks Quick and dirty ways to get marks Usually, 10-20% of total marks are allocated to simple test cases Write programs that handles these cases ONLY Use only when you have totally no idea on a task or time is running out

Tricks “No solution” Sample Input/Output Special cases Hardcoding Stop the program before execution time runs out

Demonstration (of sloppy skills) Define the value of a character be: ‘A’=1, ‘B’=2, …, ‘Z’=26 Given N strings of capital letters, sort them according to the average value of all characters. If average value of 2 strings are equal, the one which comes earlier in the input should be ranked earlier. Input: (“TOM”, “JANET”, “JOHN”) Output: (JOHN”, “TOM”, “JANET”)