由电梯调度的“两个if”想到的

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

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

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

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

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

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

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

Continue Reading

我走以后

每晚的梦都会重复
重复一段路
我们曾走的好辛苦
你感谢我付出
更感谢我退出
说她更需要照顾

听说你比从前幸福
我只有满足
还能有怎样的企图
当初你的迷了路
选择我的脚步
是不是有点唐突

喧闹的人群中
陌生的面孔匆匆略过
感觉每张脸都是你的轮廓
黎明破晓后
多想再一次亲吻你刘海遮住的额头安慰我

我走以后
你现在的生活
会不会也偶尔想起我
那所谓的以后还是朋友如何去做
你曾经说我走以后
希望还有联络
能够聆听彼此的苦乐
说是在的我已不能理智对待了

慢慢学会了沉默
想把你影子摆脱
或许就不难过
夜晚没了你在我身边拥抱着习惯了

Continue Reading

牢骚直言

今天被指责工作效率下降,但自以为其实工作效率上升。本来写了一个自管理的数据访问层,让自己的开发效率提高了3倍,但是自己并没有因为开发工作量的降低而得到解放。相反的,虽然能完成相同的功能,却因为减少了代码行数被指责工作效率下降,多么可笑的逻辑啊。

昨天还在和佛祖讨论新技术引入的问题,这里确实有一个难以掌握的平衡,新技术的引入确实可以提高开发效率,但是学习新技术却又会花费额外的时间。不可能每实现一项新技术都带来三五倍于原来的效率啊,那么这些学习的时间又靠什么来弥补呢?

还有就是最讨厌做的文档了。其实我主观上并不讨厌Word和PPT,只是每次做文档时都要讲求文档的完备性,像隔壁那位仁兄打印的东西顶多只能算开发手记,是不登大雅之堂的。一时间方便自己理清思路没有问题,但绝对不可能在日后起到指导开发或沟通设计思想之用。大概这也是我写文档花时间长的原因之一吧。

不论如何,设计还是要做的,代码还是要编的,文档还是要写的,队伍也还是要管的。只好发牢骚一篇,省心。

Continue Reading

永生

佛已入灭,人称永生,实为涅槃,大智大悟之尊者方可获得。从世俗人的角度来看,佛掌握着永生之道,但以佛家的眼光,永生本蕴涵于尘世万物之中。

佛家的永生,靠的是炼化自己的冤孽,凝神敛气,从而进入一种精神上的无形不灭的状态。

有人说:凤凰复活便是涅槃,野鸡重生却是尸变。正道出了生命于不同人和物的境界不同。僧人们修身养性,其实不能长生不灭,但是却能改变自己对世间万物的理解,悟出人生的真谛。

Continue Reading