1 / 22

HKOI Programming

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

uyen
Download Presentation

HKOI Programming

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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: • To make you understand what the correct output format is • 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”)

More Related