tsp的理論和實踐系列(5)多起點的任務分配

tsp目錄

1. 最簡單的實踐 juejin.im/post/5d1b14…
2. 最簡單的理論 juejin.im/post/5d1b15…
3. 當前tsp的現狀 juejin.im/post/5d1b19…
4. 單起點任務分配 juejin.im/post/5d1c6d…
5. 多起點任務分配 juejin.im/post/5d1dbe…
6. 更簡潔的多起點分配 juejin.im/post/5d1dc2…
7. 起點時間窗 juejin.im/post/5d1f1f…
8. 終點時間窗和hk juejin.im/post/5d1f44…
9. LK簡介 juejin.im/post/5d25b8…
10. tsp系列暫停一下 juejin.im/post/5d302e…

tsp領域的問題, 並不都是tsp問題, 可是, tsp相關的算法通常都能解決, 只要你能爲某一個充滿個性的問題兒子找到他親生的解決方案爸爸.

上一篇, 咱們乾淨漂亮的用生成樹算法解決了單一塊兒點的配送分配問題. 這一篇, 咱們面臨了更嚴峻的挑戰.

問題概述

1. 隨着業務的擴張, 你有了更多的倉庫/取件點.
2. 隨着業務的擴張, 你開始接受不少友商的訂單, 致使你的取派點的比例從1:300, 一直降低到接近1:3, 也就是說平均一個取件點只有3個目的地, 甚至於不少都是1個目的地的訂單.

思考

剛剛看到這個問題的時候, 感受上最小生成樹已經不夠用了, 那麼怎麼辦? 咱們想到了一個很直觀的方法.

• 每一個配送員均可以有一個路徑. 新的訂單分配給誰? 取決於這個訂單加入以後, 誰的路徑增長的值最小, 簡單地說就是成本最小原則.
• 這基本上是一個克魯斯卡爾算法, 多個訂單進來, 每次都把開銷最小(插入隊列後造成的權重最小, 就是新增里程最小)的一個插入配送隊列. 每次插入以後再更新一下這個被插入的隊列(路徑)對全部剩餘訂單的權重.

大約用了2天時間, 我實現了這個算法, 卻悲哀的發現, 他雖然是一個多項式時間的算法, 可是開銷達到了n的3次方, 雖然用強勁的機器, 或者引入並行運算就能解決, 可是, 這個算法還有一個關鍵的弱點: 不夠簡潔, 將來擴展會很困難, 因此, 咱們應該繼續尋找更好地算法. 此時, 我想到了參考友商的方案.

友商公開的方案

方案一, 二分圖

• 可是, 很遺憾, 咱們實際的數據邏輯是: 某個訂單的起點和它的終點關係比較緊密, 而不一樣的訂單的起點之間沒有什麼關係. 這個二分圖抽象並沒有明顯的業務實際含義, 相反, 它引入了一個沒必要要的複雜度.

方案二: 多邊形

• 尺度問題, 只要a-a足夠長, 那麼順輪的b-b訂單就不會給他. 由於面積比下面的c-c-b-b大
• 方向問題, 訂單的方向和順路由很大的關係, 每一個訂單都要先取後送, 而計算面積的時候, 卻沒有考慮這個, 會致使錯誤的分配.
  • 好比途中的b-b會分給a-a仍是c-c呢? 從橙a出發, 明顯不如橙c出發順路. 可是面積不這麼看, 並無考慮,
  • 因爲路線方向的影響, 上面的aa線路只是少走了一條短邊, 下面的cc線路會少走一條唱片
  • 上面的線路是a取-a派-b取-b派, 而下面的線路是c取-b取-b派-c派

至此感受咱們走到了死衚衕, 若是要突破, 咱們須要更有力的工具, 各位大爺別急, 我們下回分說