演算法怎麼用

travelling salesman problem (TSP)這樣子的問題是學生在修演算法或是圖論時應該都會碰到的問題，這類的問題可以轉化成很多資源分配的問題，非常有用。這個很古典的問題在Connectionist Model (aka. Neural Network)的現身年代有了新解法，而Hopfield 的解法一直到千禧年後都還有論文，請有興趣的人查一下便知。

多數資訊系的學生上過的演算法與圖論後什麼時候會真正拿來用呢？或者說，遇到可以採用類似方法的問題時知道要拿出來用嗎？

假如是電腦鼠（或迷宮），只要走出去就好也許還用不到，如果問題再複雜「一點點」，演算法與圖論就派上用場了。

講得大一點，當你有一個阿里巴巴或是沃爾瑪的倉庫要管理實體貨物時，你就知道這些東西的好用了。

下學期的自走車實境對戰的課程設計上想要讓學生體會一下，看看能不能用這些方法在比賽時獲勝。

不過這是我理想中的學生樣貌，也就是利用過去所學方法解決問題拿到高分。但是想像往往豐滿，現實卻很骨感。往年我發現學生把車子組好到只有能動的階段就開始寫code，卻沒想到去用自己過去所學，或者，更進一步的，去網路上找資料來自學。這門課有一個「被」安上去的名詞，「物聯網」，上課用的也確實是物聯網晶片7697，隊友間如果利用課程提供的架構互相聯繫資訊應該贏面會大很多，結果90%的隊伍三輛車子根本完全沒聯繫，各玩各的，然後罵這門課跟物聯網毫無關係。

順帶的說，過去不是沒有學生沒想過用演算來對戰。但是大家都忽略了一件事，假如你無法充分了解自己的車子的性能以及你的程式行為，這些演算法根本就無效。

不少人一定會說，哎呀！這個演算法不好啦！問題是所有演算法要有效一定有先備條件，不是它不好，是先備條件沒被滿足。

來修這門課的同學，要能問自己

1. 我了解我的車子嗎？
2. 我了解我的程式行為嗎？

也就是妳是你的車子的主人嗎？這就類似造物主造出了人，卻不知道人會怎麼做一般。

對了，要合作就要溝通，自己沒做到這點就不要怪這門課跟物聯網無關。

感謝 MediaTek Foundation 聯發科技教育基金會的贊助。