受兆本影响，我也来发图

Slideshow:

九月突然就过了，除了中秋回了一趟家，返回北京后改了几个Bug以外，似乎没有什么说得出来的事情，全然浑浑噩噩地过了。

今天超度一下九月吧，然后开始更新。Blog的标题改了，觉得原来那个太玄了，结果选来选去，改了一个更玄的。

客问：“借问酒家何处有？”

牧童：“靠，你丫不会自己百度啊？”

客怒：“废话，要是百度找得到，我问你干嘛？！”

奥运，GFW开始变得仁慈一些了，但是Blogger.com似乎在忙着改版，不太好打开。今天打开一看，原来填标题的地方前面赫然写着两个大字“职务”。想必是Title的机器翻译结果。

今晚回家路上，和茧聊起电梯调度算法。说一般的电梯都有省时和省电两种不同的工作模式。处于省时模式下时，系统会调度多部电梯应对不同的呼叫，以保证每个呼叫楼层的人都能最快坐上电梯；而处于省电模式下时，系统会调度尽量少的电梯应对多个呼叫，以确保满足运输要求的同时尽量节约用电。

后来随口问茧，如果让他写个电梯调度程序，怎么实现。他直接回答：“用两个if就解决了呗。”于是我开始和他讨论一些复杂的情况。比如省时模式下多于两个楼层同时呼叫电梯，该把各个电梯调到哪些楼层才能保证大家平均等待时间最短；还有如果省电模式下呼叫数量超过一部电梯的运输能力，该如何调度多部电梯；以及如果呼叫楼层集中于低层，却偏偏有一个高层客户呼叫电梯之类情况。

讨论就这么展开了，情况也越发地复杂起来。假如是一座100多层的摩天大楼，拥有好几个电梯群，总共几十部电梯，每个电梯群又有高区、中区、低区电梯，这时该如何调度。还有如果电梯乘客的不总往返于一层和所在层之间，而是分散地需要前往餐厅层、健身房层、停车场层等等如何应对。另外，调度系统该如何处理早上上班时间，中午午餐时间，晚上下班时间的人流向不均衡状况；又该如何应对工作日和休假日人流分布不同的情况。更有甚者，假如某个公司在楼内宴会厅召开重要发布会，导致突发性人流猛增的情况，电梯调度系统又该如何应对，才能既保证乘客体验又兼顾能源消耗。

这些问题提出之后，大家都认为电梯问题是一个人工智能领域的大问题，很难很有效地解决。这大概也是为什么那么多大楼物业公司还在雇佣电梯司机的原因。

回到宿舍之后，又回忆起这次讨论，突然发现“两个if”的判断和当年吕老师所说的把大象放进冰箱的思路出奇地像。嗯，茧果然颇具慧根。有些问题看上去很简单，但是却也满复杂；而有的问题满复杂，却也能考虑得很简单。自顶向下程序设计的思路，不就是从“打开冰箱，放入大象，关上冰箱”这么简单的一句话开始的么？只是如何入大象再慢慢细化和优化罢了。

电梯问题也是如此，先想好“两个if”，反正电梯调度总离不开省时和省电。只是什么时候使用省时模式，什么时候使用省电模式，再细化好了。而省时模式和省电模式下特殊的几种情况，也可以从“两个if”之后开始加以求精。

总之，从今晚的讨论来看，茧的基本思路还是对的，只是后面思维拓展考虑的少了一些。