pair work 算法总结

这次的pair work内容是要求电梯的调度。

刚刚和黄杨商量算法的时候吧不觉得这个算法有多复杂，特别是定下了先做到把每个人都能送到预定的目标，不要求别的东西的基础程序，就先写下了一些简单的电梯调度次序：

初稿1.0

调度次序：1）先调度在执行的电梯，尽可能的保留空闲电梯。调动的要求是：正在行动&&经过需求楼层&&行动方向和需求的方向一致。2）如果没有1，就调动空闲电梯。调度空闲电梯的次序：从局里需求楼层最近的电梯开始下达命令&&重量最轻的电梯。

最初就觉得大概得这么执行，后来发现还存在特别多的问题。后来不断地查漏补缺，首先是完成了一个能把人送到而不计效率不存在bug的算法

终稿1.0

Baka Bus 算法详解： 功能分解为 Scheduler 和 Task
Scheduler 功能：接受并且缓存请求，分配给每个电梯的Task。Task 功能：收到Scheduler指定的任务，指挥电梯运动。

Task 逻辑详解：Task 可以理解为电梯的当前任务，其有三个重要成员变量，State（任务状态），TaskDirection（任务方向），TaskFloor（任务楼层）。

State有三个状态
Idle（空闲）：即电梯当前没有任何任务，停止在某一楼层状态。
Pick（接人）：即电梯在空闲时，收到一个Scheduler指定来的Direction请求，即有乘客要求上电梯时，电梯驶向乘客方向去接人的状态。 Drop（下人）：即电梯在任何时候收到一个Scheduler指定来的Destination请求后，电梯按着TaskDirection方向行驶，并且在需要停靠的楼层开门使人上下的状态。

电梯初始状态一般是 Idle，会顺序地从
Idle -- 收到请求 --> Pick --到达呼叫楼层--> Drop --按着TaskDirection方向走到最后一站--> Idle

经历这些状态。 Scheduler 循环逻辑过程：

收到请求：按照请求类型（Destination or Direction）缓存。 循环过程：首要分配Destination类型请求，次要分配Direction类型请求，之后更新电梯的超重状态。

分配Destination请求：
记 该请求的电梯的Task 为 tsk。
如果该tsk的TaskDirection方向与前往 destination 的方向相同，则成功分配；否则不成功
分配成功，则移除该请求；否则，保留在请求列表。

分配Direction请求：
遍历所有电梯，优先寻找一台“顺路”电梯，“顺路”满足下面条件中任一
1、状态为Idle && 未超重 && 正好停在该楼层 2、状态为Pick && 未超重 && 任务方向和请求方向一样 && 路过该楼层或者正在行驶的方向和任务方向相反
3、状态为Drop && 未超重 && 任务方向和请求方向一样 && 路过该楼层
如果找到则马上返回分配成功，否则次要搜索一台停在任意楼层的空闲电梯。

分配成功，则移除该请求；否则，保留在请求列表。

更新超重状态：
为了确保不会出现电梯停机的问题，这里用了比较极端的处理方式，Baka Bus 认为只要剩余空间少于 120 KG 的给定最重体重时即处于超重状态。

上述算法是不计较效率的，拿第三组数据结果大概是900多，后来进行了我们商量修改算法，提出了三次的优化：

1.0优化是每次调度跑过去所需时间最少的电梯去呼叫楼层，计算电梯跑过去所需时间只计算和目标楼层相差几个楼层*每个楼层所需时间，
1.1 优化，修改电梯跑过去所需时间的算法，原基础上跑过去过程中所需停止的几个楼层*停在楼层的时间
1.2 优化，挑选时间最快的电梯过去，如果过去时间相等，那么优先派遣空余空间更大的电梯

这样之后的第三组数据的时间大概是到625.但是黄杨大神依旧不满意，提出了优化2.0

2.0优化：主要是针对状态机的优化,暂时还没有完工，不便多说

转载于:https://www.cnblogs.com/lzplzp/archive/2012/10/19/2730934.html