電梯排程演算法 軟工 Pair Project

軟工要求的結對程式設計，隨機分組，然後，我和七班的郭立軒(學號後三位196)分在了同一組。之前並不認識，雖然如此，這次結對程式設計的經歷還是相當愉快的，也學到了不少東西。

ok，下面進入正文

我以為，結對程式設計的精髓在於溝通和監督。所謂溝通，就是結對的兩個人能夠對所遇到的問題提出想法，並和另乙個人去討論，從而達到乙個取其精華，取其糟粕的效果，程式也就會比乙個人在寫會更好。所謂監督，其實可以說是一種長時間的相互勉勵以及警醒，可以讓一些在乙個人程式設計時容易出現的問題，比如錯字、分心等，機率降低，保證**的質量，也會讓人能夠保持一種高昂的精神狀態。

我和我的partner

在一起程式設計時，是可以比較明顯的感覺出結對程式設計和兩個人分別程式設計的差別的。最明顯的就是，結對程式設計時，有人在旁監督，錯誤率要下降好多，對自己的**的要求也更加嚴格。同時，通過對一些細節問題的**，也讓程式更棒。

我在這次結對程式設計體驗中的總結

好處是：

1，兩個人商量，更容易想到好的演算法

2，兩個人輪換程式設計，可以減少程式設計帶來的疲勞感

3，分工合作，編碼者專注於編碼，導航者專注於分析與設計，保證**的高質量

缺點是：兩個人觀點不一時，需要時間去相互說服，而且又是還不一定能說服，這就需要各自去證明自己的觀點的正確性，可能造成兩人之間的衝突（當然，如果沒有衝突，這一點可以算作是優點。。）。而且若兩個人不熟悉，溝通相對來說比較困難。

呃，這個評價是自己在結對程式設計的過程中，親身得出的體驗，以及兩個人對自己的評價綜合了一下。。

我自己：

優點1，有一定的編碼能力

2，容易溝通，易於相處

3，能夠提出經過自己思考的想法，並充分交流

缺點：有時過於固執，敲**是經常敲錯，不善於和

閆生輝：

優點1，勤學好問

2，容易溝通，易於相處（呃，其實感覺在學校裡，同學之間都沒問題。就是不知道公司裡，還是不是所有人都是容易溝通，易於相處）

3，能夠獨立思考（這一點是相當重要的一點，乙個好的程式，必然需要經過程式設計師自己的獨立思考）

缺點：編碼能力相對欠缺（在校大學生的編碼能立存在普遍問題，這不僅僅是學生個人的問題，也是教育本身的問題）

具體來說，對於請求佇列，依次處理每乙個請求。對於乙個請求，如果是電梯外的請求（direction request)

計算出可以響應該請求的並且能夠最快到達該請求發起的樓層的那部電梯，將樓層號加入到電梯的處理佇列。請求佇列處理之後，遍歷所有電梯，若電梯已經完成所有的請求，根據是否為上班高峰期，排程電梯至1

層。判斷是否為上班高峰期

if countreq / (double) courntreqfrom01 >cut_line:

peek()
else
: not_peek()

在為每個請求尋找最佳電梯時，需要滿足如下條件

(elev.historydirection == dirction.no ||req.updown == elev.historydirection &&req.updown == elev.currentstatus.currentdirection) &&elev.freecapacity >= max_weight

一些引數的設定

在演算法整體寫出來之後，還需要設定一些引數，以優化電梯的排程速度。下面是兩個重要的引數

cut_line = 0.5; //

是夠為高峰期的判斷界限
max_weight = 120; //
這個名字起得不好。。當電梯剩餘空間小於max_weight時，電梯不響應directioreq
floor_to = 1; //
這個是電梯在沒有請求時，自動返回的樓層。取1時，效能優於去0時大約60%。。

軟工要求的結對程式設計，隨機分組，然後，我和七班的郭立軒(學號後三位196)分在了同一組。之前並不認識，雖然如此，這次結對程式設計的經歷還是相當愉快的，也學到了不少東西。

ok，下面進入正文

我以為，結對程式設計的精髓在於溝通和監督。所謂溝通，就是結對的兩個人能夠對所遇到的問題提出想法，並和另乙個人去討論，從而達到乙個取其精華，取其糟粕的效果，程式也就會比乙個人在寫會更好。所謂監督，其實可以說是一種長時間的相互勉勵以及警醒，可以讓一些在乙個人程式設計時容易出現的問題，比如錯字、分心等，機率降低，保證**的質量，也會讓人能夠保持一種高昂的精神狀態。

我和我的partner

在一起程式設計時，是可以比較明顯的感覺出結對程式設計和兩個人分別程式設計的差別的。最明顯的就是，結對程式設計時，有人在旁監督，錯誤率要下降好多，對自己的**的要求也更加嚴格。同時，通過對一些細節問題的**，也讓程式更棒。

我在這次結對程式設計體驗中的總結

好處是：

1，兩個人商量，更容易想到好的演算法

2，兩個人輪換程式設計，可以減少程式設計帶來的疲勞感

3，分工合作，編碼者專注於編碼，導航者專注於分析與設計，保證**的高質量

缺點是：兩個人觀點不一時，需要時間去相互說服，而且又是還不一定能說服，這就需要各自去證明自己的觀點的正確性，可能造成兩人之間的衝突（當然，如果沒有衝突，這一點可以算作是優點。。）。而且若兩個人不熟悉，溝通相對來說比較困難。

呃，這個評價是自己在結對程式設計的過程中，親身得出的體驗，以及兩個人對自己的評價綜合了一下。。

我自己：

優點1，有一定的編碼能力

2，容易溝通，易於相處

3，能夠提出經過自己思考的想法，並充分交流

缺點：有時過於固執，敲**是經常敲錯，不善於和

閆生輝：

優點1，勤學好問

2，容易溝通，易於相處（呃，其實感覺在學校裡，同學之間都沒問題。就是不知道公司裡，還是不是所有人都是容易溝通，易於相處）

3，能夠獨立思考（這一點是相當重要的一點，乙個好的程式，必然需要經過程式設計師自己的獨立思考）

缺點：編碼能力相對欠缺（在校大學生的編碼能立存在普遍問題，這不僅僅是學生個人的問題，也是教育本身的問題）

具體來說，對於請求佇列，依次處理每乙個請求。對於乙個請求，如果是電梯外的請求（direction request)

計算出可以響應該請求的並且能夠最快到達該請求發起的樓層的那部電梯，將樓層號加入到電梯的處理佇列。請求佇列處理之後，遍歷所有電梯，若電梯已經完成所有的請求，根據是否為上班高峰期，排程電梯至1

層。判斷是否為上班高峰期

if countreq / (double) courntreqfrom01 >cut_line:

peek()
else
: not_peek()

在為每個請求尋找最佳電梯時，需要滿足如下條件

(elev.historydirection == dirction.no ||req.updown == elev.historydirection &&req.updown == elev.currentstatus.currentdirection) &&elev.freecapacity >= max_weight

一些引數的設定

在演算法整體寫出來之後，還需要設定一些引數，以優化電梯的排程速度。下面是兩個重要的引數

cut_line = 0.5; //

是夠為高峰期的判斷界限
max_weight = 120; //
這個名字起得不好。。當電梯剩餘空間小於max_weight時，電梯不響應directioreq
floor_to = 1; //
這個是電梯在沒有請求時，自動返回的樓層。取1時，效能優於去0時大約60%。。

電梯排程演算法

在高峰時間，實習生小飛常常會被電梯每層樓都停弄得很不耐煩，於是他想出了這樣乙個辦法 由於樓層並不高，那麼在繁忙的時間，每次電梯從一層往上走時，我們只允許電梯停在其中的某一層。所有乘客都從一樓上電梯，到達某層樓後，電梯聽下來，所有乘客再從這裡爬樓梯到自己的目的層。在一樓時，每個乘客選擇自己的目的層，電...

電梯排程演算法（ ）

今天我們做的是乙個結對程式設計作業，其實對結對程式設計，我也有兩種看法，第一 提高自己，第二 埋沒自己。關鍵看是如何去利用結對程式設計，才能達到事半功倍的效果。這次我們做的是乙個關於電梯控制排程的程式，這個程式的演算法思想做了一天，初步有了電梯排程演算法的框架。由於電腦換了，拿到聯想服務站維修，只在...

電梯排程演算法 C

1.演算法解析 掃瞄演算法 scan 又稱電梯排程演算法，scan演算法是磁頭前進方向上的最短查詢時間優先演算法，它排除了磁頭在盤面區域性位置上的往復移動，scan演算法在很大程度上消除了sstf演算法的不公平性，但仍有利於對中間磁軌的請求。電梯排程演算法是從移動臂當前位置開始沿著臂的移動方向去選擇...