HKOI Programming

HKOI Training Team (Intermediate)

2005-01-15

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”)