学霸：我老师全是学科大佬！ 第六十七章 ：两秒！

第六十七章：两秒！(第1/2页)

“这并不难看出来。”

对上许志远那带着些诧异疑惑的目光，韩川轻轻笑了笑，开口解释道。

“因为与普通的分层结构相比，基于公共交通系统建立的分层绕不开换乘枢纽。”

“你刚才说用协调参数来处理交叉变量，这在交通流量那道题里是可以的。”

“因为交通流量那道题的交叉变量只有一对一的耦合，第一层的区域A和第二层的区域B共享一条道路。一对一的耦合，协调参数就够了。”

“但更复杂的公交-地铁-步行立体线路很难。”

说着，他指了指屏幕上的公交系统网络示意图。

“一个换乘枢纽在很多时候会对应多条线路，它不仅可能是骨干层，还可能是支线层，甚至连入接驳层都是可能的。”

“就比如西直门、东直门这些站点，它们不仅交通流量巨大，而且还连接了多个不同分层，不同结构的路线。”

“在分层框架里，这种被多个层共享的节点，就是交叉变量。”

“普通的协调参数是很难处理这种复杂的共享关系的。你在用协调参数迭代的时候，会同时收到来自几十条线路的更新信号，这些信号互相冲突，协调参数很难进行同时处理。”

“所以你即便是通过分层结构来在一定程度上分离了不同线路的数据，但在涉及到换乘枢纽的时候，传统的方法依旧很难甚至是无法处理这个问题。”

听完韩川的解释，许志远盯着屏幕上的网络示意图思索了起来：“如果不用协调参数的话，这里能用什么方法解决这种多对多的耦合数据？”

的确，在构建模型和代码的时候，出现的问题正如韩川所说的一样，在计算这些换乘枢纽的时候，数据量过于庞大难以通过协调参数处理。

韩川想了下，从桌上拿过一张空白的稿纸，在上面画了一个对应的分层图层。

不过相对比许志远在电脑上建立的多层结构来说，他画的图层要多一个新的结构。

将纸张递了过去，他开口道：“我觉得可以把这些交叉变量，也就是换乘枢纽统一归到一个独立的层级里去处理。”

“这个层级不负责任何具体的公交线路优化，只做一件事，汇总所有层对同一个换乘枢纽的使用需求，然后通过算法进行统一分配。”

“这样一来，整套交通系统就可以并行两种不同的算法。”

“你设置的骨干层、支线层、接驳层在求解自己的线路优化问题时，都会用到换乘枢纽。但它们不能自己决定枢纽怎么用。”

“它们把自己的需求报给共享层，共享层再汇总所有层的需求，在枢纽容量的约束下，统一分配。分配完了之后，各层再根据分配结果调整自己的线路方案。”

“如果调整之后产生了新的需求变化，就再报给共享层，再来一轮分配。”

“反复迭代，直到所有层的线路方案和共享层的枢纽分配方案互相一致。”

听完韩川的解释，许志远诧异地看了过来，蹙眉问道：“这样计算量不同样还是很大吗？”

韩川摇摇头，道：“并不会。”

“因为共享层处理的不是原始的线路数据，而是各层提交上来的需求汇总。”

“需求汇总的数据量相对较小，因为一个换乘枢纽，不管连接多少条线路，在共享层里只对应一个变量：该枢纽的总换乘流量。”

（本章未完，请点击下一页继续阅读）第六十七章：两秒！(第2/2页)

“你原来用协调参数处理的时候，每一条经过西直门的线路都要和其他所有经过西直门的线路做配对协调。”

说着，他提起笔，在稿纸图层边重写了一个算式。

“假设西直门有n条线路经过，协调参数的数量是O(n)。”

“那么在共享层里，这n条线路各自向西直门提交一个需求值，共享层只需要处理一个变量。”

“也就是说，西直门的枢纽容量分配，那么复杂度从O(n)降到了O(n)。”

“更重要的是，这个O(n)的过程是有解析解的，即【L(x，λ)=i=1∑n(xdi)2 λ(xC)】”

“其中d_i是第i条线路提交的需求值，x是共享层分配给该枢纽的总流量，C是枢纽容量上限，λ是拉格朗日乘子。对x求导，令导数为零.....”

许志远看着那个矩阵表达式，沉默了几秒。

然后他把韩川的稿纸拉过来，对照着上面的公式，开始修改自己的MATLAB代码。

屏幕上的代码一行行流畅地刷过，不到半个小时左右的时间，许志远把代码粘进主程序里，然后打开题目附件里的站点数据文件，配好输入参数，按下了运行键。

屏幕上没有立刻跳出结果，MATLAB的命令窗口里，光标一闪一闪地，正在跑迭代。

等了大概两秒的时间，结果出来了！

两秒！

看着屏幕上的结果，许志远下意识地以为是程序出buG了。

这速度，是不是也太快了？

他滚动鼠标，仔细地检查了一下迭代日志，从头到尾看了一遍。

第一轮迭代，共享层收到来自三层共一百二十条线路的需求数据，汇总成三十七个枢纽的容量分配方案。

第二轮迭代，需求变化量比第一轮下降了百分之七十。

第三轮，再降百分之五十。

到第五轮的时候，各层的线路方案和共享层的枢纽分配方案已经基本一致，偏差量降到了初始值的千分之一以下。

“嘶！”

“这怎么可能！？”

“五轮收敛，每一轮的计算时间不到一秒！”

“这不是超算啊？！”

看着屏幕上的结果，许志远的喉结滚动了一下。

他参加过这届建模大赛，这道题拿国一的队伍有十七支，而其中从建模到计算出结果，用时最短的也花费了足足六个小时的时间。

即便是单纯看模型计算的速度，最短也耗时半个多小时。

而现在，他用自己的笔记本电脑做测算，仅仅是两秒的时间，就完成了线路规划。

虽然说测试用的数据量远比不上正式建模大赛的数据库，但别忘了，他跑模型用的设备，也远比不上建模的计算机啊。

两秒钟！

这速度，如果放到07年的建模大赛上，用爆杀全场来形容都太保守了。

真要说，这种级别的产品，理论上已经不再是单纯的竞赛建模了，它具备了商业化的可能性！