| Lines | Bugs | Time |
|---|---|---|
| 237 | 10+ | 16h |
不想赘言。
此次的电梯作业在还没开始写时，笔者想了一些方案，到了在写的时候基本都否认掉了，可以说写的版本已经是笔者推翻了自己之前显然不够好的没有付诸实践的版本的更新。此外，笔者发现这次的代码作业并不好写，除了一些细节的地方，还有就是没有AC的结果，以至于去深究整个请求，越想越繁复，没有想到什么可以一步到位的考量，很是头大。
从笔者的理解来看，笔者写了一部很朴素（在笔者策略上的朴素）并且异常电梯。（异常即指即如果请求时刻远大于处理完其时刻之前的所有请求的结束时刻，电梯可在该极大请求时刻便到达该乘客所在楼层进行接送）
笔者之前的方案以及代码考量的是如何对请求进行选择达到最小的等待总和，如有：
1、每次只接送一名乘客，到达目的地后再去接下一位（太过朴素，等待时间总和不可能最小）
2、不断进行对当前时间（‘nowtime’）进行模拟（‘nowtime++’），然后扫一遍请求，不断重复上述过程进行编码（时间复杂度过高，虽然没有限制时间，但是也希望能尽量节约时间）
3、根据当前电梯去向与乘客所在楼层的差值，以及搭载同层等待乘客或是顺路乘客（优，但是苦于不知道如何理清头绪，后续会加入实现）
下面将叙述提交版本：
笔者代码首先将输入根据请求时刻（‘asktime’）以及（乘客所在楼层与目的楼层的差值：‘value’）进行排序（‘asktime’为第一关键字），也特判了一些特殊情况（详情见代码注释），而对于不能特判的一般情况，笔者采用的策略是——在排序完，优先接送‘value’小的乘客（显然有许多反例证明此策略不能达到乘客最小时间等待总和），对于输出，笔者只进行目的地（即中间的停靠不输出）和等待时间的输出。
笔者此次的代码虽然编写了很久，但是并没有达到笔者的预期效果，笔者仍在此期间不断修改（昨晚（2018.2.10）得知寒假后续作业均是电梯，有点头大，但是也很庆幸，这样就会真的会去做后续的改进），此次的提交是笔者这几天（2018.2.7~2018.2.11）中的最新版本，但是显然不是最后的版本，笔者也深知其中很多的错误。笔者后续打算添加电梯的运行方向以达到更优的结果（如能接送恰好连续的同一楼层的乘客，以及某几个顺路的乘客等等，当然这些都是在不影响最后最优时间的情况下去做的），以及希望能够把这部电梯当前的朴素编写成成高端点的朴素，直到最后实现正常的电梯版本。
样例有上文中提及的特殊情况（如在当前乘客进入电梯时，恰好出现了下一请求（时间连续）等等），已经已经到达目的层的奇葩请求，其实就是很水的样例
实话说是高端点的版本写不出来，只好先写成这样，代码冗长，实现功能简单，简直菜得可怕
如何改进：
1、希望能够实现上文提及的搭载顺路乘客（下文样例五并不完全是正常的顺路乘客）。目前想到的解决方法是增加电梯的当前运行方向(‘dir’)，优先接送目的楼层与运行方向相同的乘客，接送完毕后该乘客被删除（考虑出队、数组模拟链表、向量解决，笔者初步估计数组模拟或向量比较容易实现和操作）。
2、想到更为合理的排序方式（请求时刻仍为第一关键字），一次或者多次排序来解决请求，保证最后的时间相比此次程序更少或等于（如此次程序已达到最优则相等）。目前想到的解决方案是将‘dir’与乘客出发楼层做差然后多次排序。
所选样例包括了一些可能出现的特殊情况以及上文提到的所谓“异常”。
Sample1~5
Sample 1:所有乘客在同一时刻同一楼层发出请求，去往某楼层，电梯将移动至该楼层一并接送。
Sample 2:所有乘客出发楼层相同，并且此样例想要说明的是——当电梯停靠某一楼层时，当前乘客进入后，即出现了接下来的乘客请求（直到所有乘客请求结束，所请求时刻是连续的，间隔1是因为恰好为前面一位乘客进入后的时刻），所有请求在停靠后连续出现，程序中电梯会停靠该楼层直到接完该层乘客。（因为这样虽然减少不了接送时间，但是可以解决后续可能的电梯移动时间）。
Sample 3:想到说可能会有出发楼层即是目标楼层的“奇妙”请求，所以设计了这一奇葩数据。
Sample 4:该样例即解释了上文提及的电梯的“异常”之处，请求中如若出现了在解决完一部分请求后，当前时刻（电梯已到达当前最后乘客的目的楼层）足够电梯移动到下一大时刻的请求，电梯“未卜先知”（根据笔者的假设），知晓之后将出现一些足够大的请求时刻，则电梯可以在该请求时刻到达请求楼层进行接送以减少中途移动时间（等到到了请求时刻再移动必会使总等待时间加长），较为智能。
Sample 5:乘客需求方向刚好与电梯当前运动方向重合，并且乘客目的楼层均为同一层，电梯可搭载顺路上的乘客。此样例，笔者做了手脚，如若目的楼层为10，则答案是错误的，这也是笔者希望日后可以改进的地方。
PTA screenshot
