Transcript HKOI Programming

HKOI Programming
HKOI Training Team
(Intermediate)
2004-01-31
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





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
–
–

NEVER make assumptions yourself
–


Range of variables
Execution time
Ask whenever you are confused
Read EVERY word
Make sure you understand before going on
Thinking

Classify the problem
–

Compare with some past problems
–

Graph? Mathematics? Data Processing? …
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 I complete a program in 15
minutes
How to reduce code 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.
2.
To make you understand what the correct output
format is
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