github:
編寫程式的**行數
除錯的bug數
完成該次作業總耗時
245 + 265行
10 ~ 20個
12 ~ 15h
...\elevator-scheduling\
// a策略：選取當前 向上、向下、停靠 三類行動中讓另外兩類行動的乘客等待時間最小的乙個
-> a.cpp
// b策略：估計三種行動的耗時，採用預估耗時最少的
-> b.cpp
// 可預知，暴力求解
-> test.cpp
所以如果根據唯一的要求讓乘客等待總時長盡可能短來分析，不考慮電梯節能歸位之類的因素，普通電梯的scan演算法是不滿足的，應該採取貪心策略，設定一些權值來判斷。
一開始的思路就是為每個乘客的行動新增權值，然後統計歸類，確定區域性最優。
然而如何設定合適的權值計算公式這一步讓我思考了很久，試了好幾種方案。
改進策略的方法是自己做一些資料手動模擬測試。
試了一些資料感覺沒什麼問題之後，總結了下策略：
選取當前 向上、向下、停靠 三類行動中讓另外兩類行動的乘客等待時間最小的乙個
確定好這個方案之後，就正式開始用c++實現了，ide是vs2017。
寫完大概一百行，然後開始測試資料，結果全是死迴圈。
fix掉幾個粗心bug後發現還是死迴圈。
認真研究了一下，發現是最重要的選取策略實現有問題。應該對0人的情況進行特判，並且權值相同時優先滿足人多的。
修修補補，加了一大段**後，終於能正常執行了。
做了幾個特殊邊界情況的資料，果然又出現bug了：a策略無法中途掉頭。
在某些特殊的情況下，為了滿足多數人的需求，或者兩撥人方向相異時，應當能夠中途掉頭來取得最優時間。
改了一天，重構了整個演算法，甚至把核心策略改成了：
估計三種行動的耗時，採用預估耗時最少的
雖然自以為新策略應該更優一些，也能夠解決之前發現的問題，但實際上在隨機的5組資料裡，2組更優，2組不變，1組更差。
於是乾脆把新策略命名為plan b，和之前的plan a一起塞到github上去了。
之後又試著寫了未卜先知的電梯，確定最優解來比對，方法是生成全排列全部方案走一遍，找到最優的。因為演算法太暴力，所以跑起來很慢。
資料1：目的資訊同時出現，電梯應當達到理論最優解
測試結果：
b.cpp:77
得到最優解，符合**
資料2：電梯應當能夠在執行中掉頭才能得到最優解
測試結果：
b.cpp:58
中途掉頭，符合**
資料3：電梯應當不在執行中掉頭才能得到最優解
測試結果：
b.cpp:56
中途不掉頭，符合**
資料4：不同時間，同起點出發，應當盡可能搭載多個同目的地乘客
測試結果：
b.cpp:69
符合**
資料5：隨機的較大資料，觀察是否出現異常
測試結果：
b.cpp:92
電梯正常，結果可以接受
電梯排程演算法
在高峰時間，實習生小飛常常會被電梯每層樓都停弄得很不耐煩，於是他想出了這樣乙個辦法 由於樓層並不高，那麼在繁忙的時間，每次電梯從一層往上走時，我們只允許電梯停在其中的某一層。所有乘客都從一樓上電梯，到達某層樓後，電梯聽下來，所有乘客再從這裡爬樓梯到自己的目的層。在一樓時，每個乘客選擇自己的目的層，電...
電梯排程演算法（ ）
今天我們做的是乙個結對程式設計作業，其實對結對程式設計，我也有兩種看法，第一 提高自己，第二 埋沒自己。關鍵看是如何去利用結對程式設計，才能達到事半功倍的效果。這次我們做的是乙個關於電梯控制排程的程式，這個程式的演算法思想做了一天，初步有了電梯排程演算法的框架。由於電腦換了，拿到聯想服務站維修，只在...
電梯排程演算法 C
1.演算法解析 掃瞄演算法 scan 又稱電梯排程演算法，scan演算法是磁頭前進方向上的最短查詢時間優先演算法，它排除了磁頭在盤面區域性位置上的往復移動，scan演算法在很大程度上消除了sstf演算法的不公平性，但仍有利於對中間磁軌的請求。電梯排程演算法是從移動臂當前位置開始沿著臂的移動方向去選擇...