Pair ProjectII 电梯调度算法

　　时间真快，pair project II已经悄悄结束。先上以下我和pair的工作照吧。

　　Shaoqing很给力，几乎要成长为代码帝了，在这次Pair中，我更多的是负责Code Review给一些算法的建议和优化，感谢Shaoqing的工作。

　　以下是关于第二个结对编程“电梯调度程序”的总结。

 

第一周，进行接口设计：

　　Shaoqing和我的想法是电梯调度只在有需求是发生：即电梯外部有用户请求或者内部用户请求被实现（我们的框架里忽略用户进入电梯后错点或者乱点电梯的情况）时，才进行一次调度算法。因为在未发生上述情况时，电梯的运行状态是没有改变的，同样的调度算法后得到的调度指令都是一定的，也就没有每个Tick都去调用的必要。这样的设计框架能变长的额压缩测试时间，电梯调度只在需要时发生。

　　但由于我们的接口设计得实在不合适，所以最后还是用了师兄的FrameWork。当然师兄觉得上述思想挺好的，希望我们能去实现，但由于精力不允许，也就作罢了。

 

第二周，实现schedule调度算法：

　　采用的是比较大众的设计思路，这里有一篇同学写的博客，思路差不太多。我们根据模拟信息又做了一些优化：
统计电梯里指示灯亮的总次数，其中目标层在0层1层的次数，用来判定下班情况；
统计电梯外指示灯亮的总次数，其中源层在0层和1层的次数，用来判定上班情况。
（注：只是统计灯的信息，没有统计人的信息，这应该是合法的。电梯的确是没有灯亮的属性。
我们是在schedule里，维持了一个列表统计灯亮信息这洋就可以进行统计工作了，所以在未响应请求前，一层楼来的请求也只会记录为一次灯亮。电梯的确不知道外面来了多少人，但他可以知道自己被呼叫过几次）。
根据统计信息在我们的算法两个地方进行了优化：
1.计算最近目标楼层代价时：上班时，加大了当前电梯向上行进的代价，促使其偏向向下移动；下班时，加大了当前电梯向下行进的代价，促使其偏向向上移动。
2.计算最近目标楼层时（计算的优先级顺序问题）：上班时，将上层向下的请求优先级设为最低，只在顺带向下时接送他们；下班时，将下层向上的请求优先级设为最低，只在顺带向上时接送他们。

最后结果：

Test Data /people	Test1 Normal (20)	Test2 On Duty (1000)	Test3 Off Duty (1000)
Bus Schedule /Ticks	307	1025	1424
Our Schedule /Ticks	64.2	369.2	326.3
Our Schedule (optimize)	64.2	296.6	323.5

 

下班的优化效果不是很好，主要是因为下班的源请求分布比较广，电梯在没有优化的情况下已经有了比较好的调度。

我们另外考虑一种优化方法是，在normal时维持电梯的均匀分布，在On duty时维持电梯的向下倾向分布，在Off duty时维持电梯的向上倾向分布。

 

转载于:https://www.cnblogs.com/codingcrazy/archive/2010/12/12/1903760.html