【以前的文章】最後一公裡極速配送 阿裡雲演算法大賽總結 總結一下新的教訓 1.由於都是NP難題，獲得最優解用常規的方法非常困難，對於不是演算法科班出身的人來說，首先應該到網路上尋找一下論文，是否有一些好的經驗。 2.保持平常心，這種比賽獲獎很困難，生活還是要和往常一樣，只是將空餘的時間給做比賽 3.每一 ...
【以前的文章】最後一公裡極速配送 - 阿裡雲演算法大賽總結
總結一下新的教訓
1.由於都是NP難題，獲得最優解用常規的方法非常困難，對於不是演算法科班出身的人來說，首先應該到網路上尋找一下論文，是否有一些好的經驗。
2.保持平常心，這種比賽獲獎很困難，生活還是要和往常一樣，只是將空餘的時間給做比賽
3.每一個小功能，小函數，儘可能做一些簡單的單元測試，這種題目往往代碼最後非常複雜，難以調試，不做單元測試，可能以後調試都很困難
4.熟悉使用語言的多線程工作方式，例如C#的多線程特點
5.尋找好的計算資源，儘量在多核CPU上運行
6.加入官方群，問題及時和官方討論
7.利用晚上進行大規模的迭代測試和參數實驗
8.中間結果保存，減少每次執行時間。
大家都是為了獎金去的（TOP10都有獎金），TOP17的名次，和自己實力符合。
另外這次全程使用VS CODE 和 NET CORE 2.0 寫的代碼，在公司的ＰＣ和家裡的ＭＡＣ上通過ＧＩＴ無縫銜接，體驗不錯。
代碼：https://github.com/magicdict/AIForAirline
賽題：https://tianchi.aliyun.com/competition/information.htm?raceId=231609
一個人做題目很有趣，但是組隊也不錯，有人願意和我組隊參加第二賽季嗎？難度增加不少的。前三有獎金，當然如果沒有奇跡，基本上拿不到獎金的。
附上以前比賽經驗：
窮舉部分應該最後加入
一般來說,演算法題目總歸缺少不了排列組合的嘗試，但是如果過早的在演算法中引入了排列組合的大規模計算，則每次代碼運行時間會很長，非常浪費時間。這裡可以有兩個方案，第一，可以做一個系統配置項，是否啟用排列組合的嘗試；第二，可以將排列組合的強度也做成一個配置項。
所謂的排列組合的強度，就是演算法的廣度和深度的限制。例如背包問題，如果全部有10個元素，我進行全排列嘗試，20個元素，則進行簡單的貪婪演算法。這裡的10就可以認為是一個閾值，超過閾值的時候，考慮到時間成本，使用一般的演算法。
保證每次運行結果都是符合題目要求的
在複雜的場景下，你的演算法可能是非常優秀的，但是可能在一個很微小的點上，是不符合題目要求的。題目要求是最大的前提，如果違反題目要求，再好的演算法都是不能被採納的。所以務必檢查每次的運行結果是否符合題目要求。
保證編碼正確
有時候，一個想法是正確的，但是往往可能出現編碼的錯誤，使得結果變壞。所以，必須保證你的代碼和你的想法是一致的。如果出現你的想法使得你的運行結果變差的時候，不要先急著推翻你的想法，而是應該先看一下是不是你的代碼有什麼錯誤，沒有真正反映出你的實際想法。
邏輯和閾值
在複雜的演算法題目中，有時候我們喜歡用閾值來運行出不同結果，然後選擇最優的結果。但是，如果可能的話，應該以統計等方式決定閾值。如果可能的話，應該有一個明確的邏輯，而不使用閾值。閾值沒有泛用性，並且有時候由於不能測試每一個閾值的效果，容易出現局部最優解，而不是全局最優解
版本管理
不是每一個想法都會給結果帶來正面的效果，有些改動可能不但沒有效果，而且使得結果變壞，我們需要一個版本管理的概念，將不好的結果及時回滾到原來的狀態。有時候，兩個想法可能被同事加入到代碼中，並且兩個想法獨立使用和一起使用效果也不同，這個時候更加需要版本管理工具了。建議使用Git做版本管理工具，可以自由的添加或者刪減不同的想法。
自動測試 和 電源管理
這次沒有準備自動測試的代碼，正確的做法是，白天進行編碼工作，晚上對於閾值，各種想法的排列組合的效果，進行自動測試。
在自動測試的時候，請註意電源管理的設定，需要看一下是否設定了休眠，如果設定了休眠狀態，基本上什麼都運行不了了。
對於每次自動測試的結果，都必須保留下來，作為演算法的評價依據。
中間指標 和 數據分析
在最終目標之外，還需要訂立一些其他指標來判斷演算法的好壞。
整個最終結果往往是由多種因素決定的，如果將這些因素的量化結果也列印出來，對於這些指標進行分析，往往可以找到優化點。
有一些題目，在寫演算法之前，可以將題目中給定的數據集進行一些分析，總結出數據集的特征，然後針對這些特征選擇演算法，也是一個很重要的步驟。
從答案中找問題
很多演算法的最終結果可能是一些調度計劃和分配方案。仔細觀察這些結果，找到一些明顯可以優化的點，這也是提高演算法結果的途徑。
從演算法執行結果這個答案中尋找你的演算法中存在的問題，是一條很有用的途徑
