最后兩次組隊賽的題都相對簡單，所以兩次都得到較高的題目數！一次是在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	A	Relevant Phrases of Annihilation	2/22	2/5
No	B	Smart Network Administrator	3/18	3/5
?	C	European railroad tracks	0/0	0/0
?	D	Matrix Words	0/2	0/1
?	E	Little Quilt	5/11	2/2
Yes	F	Card Trick	6/6	6/6
Yes	G	CN Tower (Easy)	6/18	6/6
?	H	Matrix	0/5	0/2
Yes	I	A Game with Numbers	8/9	7/7
Yes	J	Vertex Cover	6/15	6/6

　　暑假的訓練就這樣結束，總結一下組隊的時候要注意的地方： 1.比賽的時候必須把所有的題都要讀一遍。 2.看到有思路的題都要嘗試著去想解決的方案。如果過的人比較多，而自己思路不完整，應該及時告訴隊友，讓隊友一起想解決的辦法。如果想的時間太長，應該先擱一擱，先查看其他的題目。 3.如果有一題有一種解決的方法，但是還沒能證明出來，在沒題出的情況下還是要嘗試著用，已有的想法打一遍，說不定就是這樣過了。 4.訓練的時候要注意每種算法的模型特點，因為一種算法可能出得十分隱蔽，但算法卻又十分簡單。 5.比賽的過程中，如果陷入困境，例如精度問題等，不應該花費太多時間依靠看代碼來debug，而是應該想一下，是否算法有誤，然后就是看看題意是否看錯了。最好在確定算法正確的情況下，多讀幾遍題目，把小tricks都找出來。 6.如果同時卡幾題，而且每一題都是每個人獨自解決的，要給定一個時間，在給定時間內如果分別都繼續卡，就更改狀態，變成多人解決一題的模式。 7.要會用模板，而且模板最好都是自己驗證過的，速度等優化都是相當完備的。算法的核心是必須知道的，不然看到一道題的變式就沒法想到怎么更改函數了。另外，題目的某些條件也可能讓原來的核心思想簡化，如果繼續用同一代碼就難免會超時。 8.一道很多人過的題，題目必須看懂，因為這必須是簡單題。 9.最好每個隊員都要明白算法的思想，不然隊友調試的時候就很難幫到他的忙了。 10.組隊最好就要有相似的代碼風格，如果沒有，就應該多點交流，盡可能的讓風格接近，以便debug能更快的完成。 11.（這是我們隊的一個做法，僅供參考）想問題的時候，如果問題是一些數學題等，模型沒有搞清，也不能看出怎么解決，這時就應該想問題的核心，問題的關鍵所在。 12.簡單的問題仔細化，復雜的問題認真想。如果知識達到一定的水平，問題總是可以想到解決的方案的。所以積累知識十分重要！ 暫時想到就這么多，以后還有會繼續補.... ——written by Lyon

轉載于:https://www.cnblogs.com/LyonLys/archive/2012/08/31/2012_08_30_Lyon.html

總結

以上是生活随笔為你收集整理的2012暑假最后两次组队赛总结的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。