遇到会做的题，应该用迭代开发/代码复查/生成数据等各种方法保证正确性。Coding也不宜太快，毕竟NOI的时间是充足的。

遇到大致知道方法但是写起来很麻烦的题目，不妨先花几分钟写一个Brute Force的程序放到那儿，然后在埋头Coding。那种麻烦题目一定要把思路完全理清楚了再去写，千万不要写到一半写不下去了，那是最得不偿失的。

遇到暂时想不出来的题，不用慌，慢慢分析，或者从一个垃圾程序开始慢慢迭代开发。相信自己的实力。

遇到一看便知很麻烦很麻烦的题，大胆放弃，但写个Cheat程序还是必不可少的（至少可以稳定情绪）。

注意先写程序后优化。程序的每个重要版本都要备份一下，例如第一个可以编译的版本，第一个过样例的版本，某次大改之前的版本等等。

在准备在程序中大量加入调试代码之前，先看看变量、数组的声明是否正确，看看有没有弱智错误。

近几天的安排：

任务一，每天写二至三道NOI难度或略低的题目，保持状态。

任务二，精炼一下几个（不太常写的）最基础的东西的代码：quicksort、heap、highprecition等。

任务三，打印自己写过的文章/代码看。

就这样吧。

7月11日

1. Emacs+GDB的确是正确的选择。
2. 代码复查是好习惯。
3. 双向搜索、或者说折半搜索的思想。（第三题）

7月12日

1. 越是简单的题，越是需要用DataMaker、代码复查等各种手段反复查错，保证AC。例如今天的第一题，写错太不应该了。一定要警惕在某道题上花费时间太少的情况。
2. 出现访问段异常时，如何在GDB中定位到异常的那一行？
3. 第三题那个AC程序的随机化——不断缩小随机的范围，相当神奇。

7月13日

1. emacs -nw 更好用。
2. 第三题文件名写错，300分变成200分，攒RP了。

7月14日

1. 第一次见的经典网络流题AC了还是很高兴的。Dinic果然无敌。
2. DP题还是要先慎重确定方程无误后再下手。注意贪心（第三题）。

7月15日

1. 第三题绝对是太贪了，考虑太复杂。不过也怨题目没有给出更详细的数据范围。否则我就很可能Brute Force了。
2. 第二题独立想到，图论基础还是可以的。
3. 第一题策略严重不当，想的二分答案，等二分答案的所有步骤都写完了才意识到不能直接二分（也没想到yxy那种找单调性的上下界然后二分的方法）。
4. 强调一下：先把算法想清楚再下手。
5. 细节的确决定成败，第三题明明想到了Fibnacci数，也想到了那个唯一分解的定理，但由于错误的“负Fibnacci数”的想法，导致满盘皆输。只是一个小小的偏移量就可以避免麻烦的负数。真是心有不甘啊。

7月17日

1. 多日以来攒的RP终于在今天短暂爆发，拿到了第一个真正的300。不过就像别人说的那样，这导致我今天的收获远不如前几天。但也不一定，前几天得到的是“教训”，今天得到的就是“经验”了，例如：高度模块化（大不了最后再改成inline、define），坚持迭代式的编程（滚动数组、最优性剪枝、常数优化之类的东西都一定防盗最后再搞）。看到其他几个人的代码风格真是惨不忍睹。
2. 你以为会个最短路、会个网络流就是会图论算法了吗？看看Graph-Theoric Algorithms吧。太优美了，真的。
3. Emacs学习告一段落。GDB还是做不到熟悉的静态调试那样得心应手。

7月18日

1. 第一题正确的贪心策略没有想到，用加卡时的乱搞得了一半的分数，还是很满足的。
2. 第二题做过的题20mins就写AC了，就应该这样。
3. 第三题题意太不清，忽略。

7月19日

1. 提交答案题。出现一个重大失误，在算后面的数据时由于编程序的失误把前面已经算出来的解给覆盖了……看来以后要把已经算出来的解妥善保存好。还有就是对于今天这种很可做的提交答案题，要记得分配两个小时左右的时间。
2. 交互题浪费了太多时间，似乎还是因为没有完全想清楚就开始编程的缘故。（竟然是60分而且跑出了5个极限数据中的3个？我也很惊讶……）
3. 如果有巨BT的模拟，像今天第一题那样的，放弃是最明智的选择。

上午仔细做题，注意时间分配，练Emacs，练GDB。

中午另安排。

下午要把上午的所有题都搞清楚，除非公认不可能搞清楚。

晚上总结一天。

注意珍惜时间。

根据明天的情况再细化。