| A | B | |
|---|---|---|
1 | What is this trainng? | |
2 | Training Goal | - Mentaility Shift. Mind Re-structuring. It is all about understanding your mind, its problems and how to make it better |
3 | Training Objectives | - During solving: Moving in stable and fast manner from solving phase (Reading, Thinking, Verifying, Implementing, Debuggubg, Submitting) to next - Detecting & working on Contestant solving problems (e.g. debug time > 3 min) - Detecting & Working on contestant weak points (e.g. bad performance in Greedy) - Quantitatively after 1 year: Stable yellow coder at 1700+ on TC, and similar performance in codeforces - Quantitatively after 2 years: Stable red coder at 2500+ on TC, and similar performance in codeforces...let's dream :) |
4 | Training Approach | - Discipline Monitor Approach: http://www.youtube.com/watch?v=1ArHifjTuFc&feature=youtu.be |
5 | Training Configuration | - Pair Training. The 2 contestants should have a similar performance (e.g. ~1000 in TC) + being passion / hard worker |
6 | Training Material | - How to Practice series + Basic techniques and data structures from my playlists. Training Focus is on 75% Adhocks and 25% on knowledge. |
7 | Training Problem Sources | - 150 problem from TC, most of them Div2-500 |
8 | Enemies Pairing Style | - 2 members work against each other |
9 | Twins Pairing Style | - 2 members work with each other in every thing (If reading book, read together - if solving a problem, together every phase) |
10 | Sem-twins Pairing Style | - If reading/watching task, then do it alone and then together to discuss the content. If solving, then together in certain phases (e.g. thinking) and remaining alone |
11 | Teacher Pairing Style | - 1 member solves the problem anyway, and then prepare hints to help the second to solve it in a good manner. Review the discipline |
12 | Programming Language | - Contestants should build strong background in the C++ language and Algorithms - Book: C++ Primer, Fifth Edition |
13 | Solving Discipline | - Check Problem Training style / Transition Periods - Be ready to follow ALL ur written discipline - Open logging document - Prepare envirnment and open the problem - Start to solve - record as much as you could - Your eyes on time, transit if passed time - When you get WA, don't see the testcases. Behave as if you are in a contest. - Manage to get AC - Read ur log more than time - Write analysis of all issues - How to avoid such problems next time? How to perform better? - Update discipline document - Update Errors Inspection List document - Check Editorial, see some red/yellow solutions - If something is different, learn it - Write the shortest possible code (one that you wish to write in a real contest) |
14 | ||
15 | How do we achieve Discipline? | |
16 | How to practice series | - In this series, discipline for all problem phases (Reading, Thinking, Coding...) were writeen - Contestants create checklist for every phase, and write his own guidelines, utilizing the series - Contestants is responsible for following strictly what he wrote |
17 | ||
18 | ||
19 | How do we achieve Monitor? | |
20 | Sheet Measures | - Each contestant logs during the solving the timing for each phase and what he was doing. Then, log must be analyzed |
21 | - In solving sheet, contestant measures lots of points. Also, some measures are calculated automatically | |
22 | - First, it is important to know consumed time in reading, thinking, verifying, code sketching, coding, debugging | |
23 | - Second, contestant evaluates 3 levels: text, idea and code. An automatic measure to calc the overall problem level | |
24 | - Also, recording if any cycling or transition occuered. In addition, to what degree discipline was followed in every phase | |
25 | - A performance measure is a time measure of solved time against best possible submission time | |
26 | - Finally, the count and average time consumed per category is recorded | |
27 | ||
28 | ||
29 | Clarifications in solving sheet | |
30 | Problem Transition | - Tackling problem: You are trying the problem, if failed you check editorial. If you couldn't understand the tutorial you check real solution. - To avoid consuming much time in a phase + variablility, we define transition for above 3 phases in format (N, M) - N is allowed hours to try the problem, then transit to the editoiral if you couldn't - N is allowed hours to understand the editorial, and the transit to real solutions if couldn't undersant - If allowed time passed, but you have something in mind don't transit. Transition is made for "stck status" - E.g. (2, 1) means try to find the idea maximum in2 hours. If failed, try the editoiral for 1 hour. if failed to get the idea, move to solutions |
31 | Cycling | - In sovling, The correct manner is to move from phase to next directly - Moving back to a phase wanrs about a wrong behaviour - E.g. During Thinking about solution, back to problem statement to check sure if grid is square or rectangle! - This is cycling to problem statement - E.g. While coding thought How this function will be implemented - This is cycling to thinking stage. You should think about every thing: Idea & its implementation before coding - E.g. While coding thought What is this method order? Is this greedy valud - This is cycling in verification stage - When you submit problem and fails, then you will cycle to one of phases - Good solver rarely cycles back - Back to problem statement to revise rules to have them in mind is not cycling - Cycling indicates feeling that a previous phase is done incorrectly |
32 | Perforamce Measure | - We use a tough measuer for comparison, the fastest submission in the judge for the problem - This is available mainly in TC in editoral page - Performance = Best time / Your time, then scale to 10 - Your time is your overall time + 20 * # of incorrect submissions |
33 | Thinking Time | - Time to find solution - Time to verify the solution |
34 | Problem Level | - Subjective Autmoatic measure. Thinking time = 2 Coding time. Coding time = 2 Text level. Contestants determine these 3 factors from their veiw |
35 | ||
36 | Notes & Advices | |
37 | Log of others | Use to check others log per a problem you solved. See where they behaved better than you and try to understnad why |
38 | Online Contests | Share in all online contests such as TCs and CodeForces. This will help us know how is the progress |
39 | QUORA | Read in QUORA in all posts in ACM ICPC, TopCoder, Competitive Programming .. always bookmark any important Q |
40 | ZPD | You learn from problems that you struggle to solve or need little hints. Neither work in your comfort zone (Easy problems) or tough problems (time wasteing) |
41 | Problems Categorization | Try always after solving a problem to put it in an organized directories in terms of its category. E.g. in my machine, I have folder for each category, when I solve a problem, I create a sub folder for it and set it inside the folder. By times, u have many problems in many categories. u could also divides a category folder to 3 types: Easy, Medium, Hard for better classification. Folder hierarchy Example: Graph\Dijkstra\Hard\SRM300-1-2 Graph\Dijkstra\Hard\UVA-100 Graph\Dijkstra\EASY\SPOJ-FISHES Graph\MST\Meduim\UVA-120 Math\NumberTheory\Primes\hard\... |
42 | Submission Failed! | If you submitted a code to TC and it failed, don't check the case did so. Don't corrupt ur training, In real contest no one will tell u why u failed. U should develop the skill of finding the bug reason. Depend on the inspection list to find the mistake. Keep thinking around 15 min, if couldn't know the reason, check the case, fix code and resubmit. If failed again, then for a while, say 10 min, and then recheck...and so on. Finally, update your inspection document. |
43 | Debugging tip | One of the important reasons that takes someone debugging time is the discovered mistakes. While you are debugging, you discovered ur approach is buggy in this point, then u did a fatal mistake! A quick Fix u simply tell ur self..oh not like that, but in this way..and do the fix...without any re-verification for this step, how does it affect whole solution? could be there any related point to be updated...many of Qs needed!..but we just do a simple fix be careful, any solution or solution update need verification...verification is for: time, order, correctness.... If u think code need fix..left machine..back to papers, validate there, think slowly. |
44 | Minimizing mistakes | To minimize mistakes, during debugging, log as much as you can from bugs reasons and what consumes time in debugging. work on found problems |
45 | The "Suspect & Double Check" method. | Suspect ur work (tell ur mind I am wrong, and challenge urself to find a mistake). This helps you reduce the errors, especially with hard problems. You could do that to verify every thing. The text u read. The order u calculated. The special cases in ur code (u say, who said they r special? or why handled like that). An idea u discarded (e.g. u said its order is big, we can't use this idea). A greedy algorithm that u accepted as solution...etc In many cases, u discover u did something wrong. Whenever problem takes much time in thinking, and u believe it will take a good time to sketch its code ... try this method...if u think it is helpful, add it to ur verification discipline. |