最后两次组队赛的题都相对简单，所以两次都得到较高的题目数！一次是在hdu的diy上做，另外的是在bnu做spoj的题。
先补回倒数第二场的总结。
倒数第二场一共有10题，当时过的题包括一题枚举求最大值，一题二分求概率，一题枚举求概率，还有一题网络流。上次开始的时候出题不利，刚开始就因为题目没写多case所以我就以单case打了个代码而吃了好几个wa，耗费了我近半个小时来debug。然后就是一题很水的概率统计，不过因为没有注意到边界条件wa了好几次，当时就搞到我没心情做下面的题了。接着就是队友hq发现了一题网络流，然后他想到了方法，所以我就给他抄了个isap的模板上去，后面的他自己打。不过打出来的代码质量还是相当高的，一提交就ac了！在他过网络流前，我看到了那道二分法求概率的题，然后突然间就被我想到思路了，就像是一棵线段树一样的获取区间的值。不过当时状态不好，比较暴躁，在我卡sample的时候我当时根本都没有听取队友的意见，不过当时他们的意见好像也没有对。我反复的debug，就是卡在一个位置，耗了我大半个小时想原因，最后想到这题是不用epsilon的，即便是要进行浮点运算。最后在只剩两分钟的时候提交上去，直接就是一个1y。绝杀了！那场也是关键的比赛之一，所以最后那题就显得十分关键了，也就因为那题，在那场里追平了另外一支11的队伍，保住了总题数领先1题的地位！
然后就是今天的最后决胜负的关键一场了！这场我是十分看重的，所以一到机房我就直接奔去电脑前，由我首发操刀读题目（题目如下，都是spoj的题）！刚开始，队友hq就教我看一下最后一题，是一个树的最小覆盖。说着也搞笑，今天有两题都是用着十分独特的方法，虽然运行的时间是长了，不过都过了！一题就是这个最小覆盖，真的被我用最小覆盖来过了。之前做了好多次HK算法的题目，对这个算法可谓是情有独钟，于是我就直接打这个代码上去。没打之前，因为hq对二分匹配的认识只在匈牙利算法那里，所以一度怀疑我的算法会不会超时。不过我也没怎么解释，100000个点的树，匹配只要O(m)的时间，预处理成二分图的时间是O(n)，n = m + 1。所以我心里知道这个算法是可以尝试的。然后我就叫hq不要理我，先去看其他题目。我打好了以后测了几组小数据，都过了，不过交上去wa了。当时我发现我的一个数组和一个整型的变量用了同一个符号，于是我改了一下，再交，还是wa。在我调试好二分匹配的代码前，hq已经想好了I题这个简单的博弈了。然后我根据hq的思路把代码打出来，直接交了就1y了！
接着，我就专心找我J题代码的bug，很快就被我发现了一个极其微小的错误，打多了一个等于号。我再验证了一下，sample没问题了，然后再交，这次过了~真实好事成双啊！这时hq继续看A这个后缀数组的题，然后我就继续看其他的题了。我随便按了一个，就发现了F这个求排列的题了！当时我根据题意找了一下规律，然后我根据规律的特征，想到了用线段树来解决问题。打上去的时间不长，不过求sample 的时候debug了我近20分钟，最后过了sample以后提交就是一个1y。不过赛后师兄告诉我这题的数据这么小，是应该暴力枚举的.......囧！ 然后就是A了。我帮hq打了好一个倍增的后缀数组，然后剩下的由hq来完成。不过像他说的一样，要严谨，时间会长一点。其实我想说，他将剩下的完成用了近一个钟。最糟的就是打出来的代码好多错误，例如变量重复定义，非法访问等。不过可惜我不太懂题意，没办法帮他读题。
（晚上太晚打这篇文章了，后来打着打着就睡着了，接着打下面的）
在debugA题的时候，我打了一个G题，是十分水的题。不过，一开始没看清题目，输出的时候没有符合要求，浪费了十几分钟debug了。幸亏最终还是过了！
| Yes | 2/22 | 2/5 | ||
| No | 3/18 | 3/5 | ||
| 0/0 | 0/0 | |||
| 0/2 | 0/1 | |||
| 5/11 | 2/2 | |||
| Yes | 6/6 | 6/6 | ||
| Yes | 6/18 | 6/6 | ||
| 0/5 | 0/2 | |||
| Yes | 8/9 | 7/7 | ||
| Yes | 6/15 | 6/6 |
1.比赛的时候必须把所有的题都要读一遍。
2.看到有思路的题都要尝试着去想解决的方案。如果过的人比较多，而自己思路不完整，应该及时告诉队友，让队友一起想解决的办法。如果想的时间太长，应该先搁一搁，先查看其他的题目。
3.如果有一题有一种解决的方法，但是还没能证明出来，在没题出的情况下还是要尝试着用，已有的想法打一遍，说不定就是这样过了。
4.训练的时候要注意每种算法的模型特点，因为一种算法可能出得十分隐蔽，但算法却又十分简单。
5.比赛的过程中，如果陷入困境，例如精度问题等，不应该花费太多时间依靠看代码来debug，而是应该想一下，是否算法有误，然后就是看看题意是否看错了。最好在确定算法正确的情况下，多读几遍题目，把小tricks都找出来。
6.如果同时卡几题，而且每一题都是每个人独自解决的，要给定一个时间，在给定时间内如果分别都继续卡，就更改状态，变成多人解决一题的模式。
7.要会用模板，而且模板最好都是自己验证过的，速度等优化都是相当完备的。算法的核心是必须知道的，不然看到一道题的变式就没法想到怎么更改函数了。另外，题目的某些条件也可能让原来的核心思想简化，如果继续用同一代码就难免会超时。
8.一道很多人过的题，题目必须看懂，因为这必须是简单题。
9.最好每个队员都要明白算法的思想，不然队友调试的时候就很难帮到他的忙了。
10.组队最好就要有相似的代码风格，如果没有，就应该多点交流，尽可能的让风格接近，以便debug能更快的完成。
11.（这是我们队的一个做法，仅供参考）想问题的时候，如果问题是一些数学题等，模型没有搞清，也不能看出怎么解决，这时就应该想问题的核心，问题的关键所在。
12.简单的问题仔细化，复杂的问题认真想。如果知识达到一定的水平，问题总是可以想到解决的方案的。所以积累知识十分重要！
暂时想到就这么多，以后还有会继续补....
——written by Lyon