Download presentation
Presentation is loading. Please wait.
Published byAustin Houston Modified over 9 years ago
1
HKOI Programming HKOI Training Team (Intermediate) 2005-01-15 Alan, Tam Siu Lung Unu, Tse Chi Yung
2
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
3
Today’s flow Competition Rules Problem Solving Coding Testing Tricks
4
Competition Rules The winner is determined by – Fastest program? – Amount of time used in coding? – Number of tasks solved? – Highest score
5
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
6
The “OI” Programming Process Choosing a problem Reading the problem Thinking Coding Testing Finalizing the program
7
Reading the problem Usually, a task consists of – Title – Problem Description – Constraints – Input/Output Specification – Sample Input/Output – Scoring
8
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
9
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
10
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
11
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
12
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?
13
Characteristics of OI programs Simple Input/Output Assumption: Data input format always matches specification Short programs (usually < 100 lines)
14
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)
15
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
16
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 ”
17
Testing Create some simple input yourself (by hand) Boundary cases “Large” input – Test for execution time and integer overflow Tricky cases
18
Debugging Print values of important variables to screen and/or files Print messages to screen and/or files Use debugger – FreePascal IDE debugger – GDB
19
Finalizing Check I/O filename Check output format – Any trailing spaces? Correct source/executable name? Is the executable updated?
20
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
21
Tricks “No solution” Sample Input/Output Special cases Hardcoding Stop the program before execution time runs out
22
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”)
Similar presentations
© 2025 SlidePlayer.com. Inc.
All rights reserved.