最後一千米極速配送 - 阿里雲算法大賽總結

時間 2019-11-08

原文原文鏈接

簡單回顧

從7月初開始參加了阿里雲的算法大賽，第一賽季得到了第14名的成績，第二賽季因爲其餘事情須要處理，得到了23名的成績。對於一個沒有受過專業算法訓練，第一次參加算法比賽的我來講，成績仍是比較合理的。算法

經驗總結

窮舉部分應該最後加入
通常來講,算法題目總歸缺乏不了排列組合的嘗試，可是若是過早的在算法中引入了排列組合的大規模計算，則每次代碼運行時間會很長，很是浪費時間。這裏能夠有兩個方案，第一，能夠作一個系統配置項，是否啓用排列組合的嘗試；第二，能夠將排列組合的強度也作成一個配置項。
所謂的排列組合的強度，就是算法的廣度和深度的限制。例如揹包問題，若是所有有10個元素，我進行全排列嘗試，20個元素，則進行簡單的貪婪算法。這裏的10就能夠認爲是一個閾值，超過閾值的時候，考慮到時間成本，使用通常的算法。編程
保證每次運行結果都是符合題目要求的
在複雜的場景下，你的算法多是很是優秀的，可是可能在一個很微小的點上，是不符合題目要求的。題目要求是最大的前提，若是違反題目要求，再好的算法都是不能被採納的。因此務必檢查每次的運行結果是否符合題目要求。編程語言
保證編碼正確
有時候，一個想法是正確的，可是每每可能出現編碼的錯誤，使得結果變壞。因此，必須保證你的代碼和你的想法是一致的。若是出現你的想法使得你的運行結果變差的時候，不要先急着推翻你的想法，而是應該先看一下是否是你的代碼有什麼錯誤，沒有真正反映出你的實際想法。工具
邏輯和閾值
在複雜的算法題目中，有時候咱們喜歡用閾值來運行出不一樣結果，而後選擇最優的結果。可是，若是可能的話，應該以統計等方式決定閾值。若是可能的話，應該有一個明確的邏輯，而不使用閾值。閾值沒有泛用性，而且有時候因爲不能測試每個閾值的效果，容易出現局部最優解，而不是全局最優解測試
版本管理
不是每個想法都會給結果帶來正面的效果，有些改動可能不但沒有效果，並且使得結果變壞，咱們須要一個版本管理的概念，將很差的結果及時回滾到原來的狀態。有時候，兩個想法可能被同事加入到代碼中，而且兩個想法獨立使用和一塊兒使用效果也不一樣，這個時候更加須要版本管理工具了。建議使用Git作版本管理工具，能夠自由的添加或者刪減不一樣的想法。大數據
自動測試和電源管理
此次沒有準備自動測試的代碼，正確的作法是，白天進行編碼工做，晚上對於閾值，各類想法的排列組合的效果，進行自動測試。
在自動測試的時候，請注意電源管理的設定，須要看一下是否設定了休眠，若是設定了休眠狀態，基本上什麼都運行不了了。
對於每次自動測試的結果，都必須保留下來，做爲算法的評價依據。優化
中間指標和數據分析
在最終目標以外，還須要訂立一些其餘指標來判斷算法的好壞。
整個最終結果每每是由多種因素決定的，若是將這些因素的量化結果也打印出來，對於這些指標進行分析，每每能夠找到優化點。
有一些題目，在寫算法以前，能夠將題目中給定的數據集進行一些分析，總結出數據集的特徵，而後針對這些特徵選擇算法，也是一個很重要的步驟。阿里雲
從答案中找問題
不少算法的最終結果多是一些調度計劃和分配方案。仔細觀察這些結果，找到一些明顯能夠優化的點，這也是提升算法結果的途徑。
從算法執行結果這個答案中尋找你的算法中存在的問題，是一條頗有用的途徑編碼

算法和人生

算法比賽和人生有不少相識的地方，有一些算法在肯定的時候，就決定了可以作出什麼樣的結果。
一個很差的算法，再怎麼優化，得出的結果可能都比不上一個未經優化的好算法。固然，一箇中庸的算法，雖然沒法達到進過優化的好的算法的結果，可是每每能夠接近一個未經優化的好的算法的結果。人生也是如此，選擇比努力更重要。
引伸開來，算法有時候也不能太轉牛角尖，在一些小的局部細節上斤斤計較，而忽視了一些起決定性的因素。固然，這一點提及來容易作起來難。人人每每容易在微觀的，局部的領域裏面錙銖必究，而忘記從大局上找到問題的關鍵點。按照中心極限理論，有一些次要的因素，有些使得算法變好，有些使得算法變壞，可是這些因素的綜合做用每每是相互抵消的。code

編程語言

從算法層面來看，OOP的各類語言都是差很少的。不少人喜歡爭論語言的優劣，其實若是真正研究算法和運籌學的，語言的優劣其實根本能夠不用去考慮。使用你本身習慣的語言就能夠了。我用C#習慣了，因此每每能夠用C#的各類特性來簡化代碼，特別是Lambda和Linq這樣的特性，熟練掌握的話，每每能夠將負責的功能用簡單的代碼實現。若是真正靜下心來，研究一些算法或者AI大數據的時候，你是根本沒有時間和興趣加入語言優劣的論戰的。