经过五个多小时的运行，程序最终输出来了。
结果如之前所示，有点问题。与真正的统计结果相差还蛮大的。现在我们这里能找到的原因有以下2个：
列车时刻表
应该是原始数据有问题，所以导致输出时刻表也出现问题。就是某次列车在前几个区间还是有到站发车时刻数据的，但到了最后几个区间却出现了数据丢失的情况（上下行都有），即下图中标黄的部分。如果乘客在此次列车上，到了真正下车的区间时间却显示为0，这个是否会对最后客流的时间段分配情况产生影响？
系数矩阵
这个之前已经通知您了，就是乘车时间，换乘时间均是以小时计算的，而程序里面所读取的时间全是按照秒来计算的。
属性
平峰
高峰
系数
系数
乘车时间(h)
-5.3029
-7.7727
换乘次数
-0.6234
-0.5299
换乘时间(h)
-9.6731
-12.8199
角度费用(m)
-3.1199
-1.8370
所以我们就对程序进行了修改，也不知道改的对不对……
现在我们在做的工作是对读取的表格进行优化。
现在这个程序进行匹配的时候是中文字符匹配，我们准备对OD表和有效路径两个数据量巨大的表进行标号。这个其实您也了解，就是每一个站对应一个编号，比如说西朗是1，坑口是2，打算采取1002或其他方式来标记这个OD对，这样进行匹配的时候用数字匹配，是不是更快一点？还有就是比如一个OD对，在有效路径里面查找它所包含的路径的时候，打算直接将其路径们所在的行号直接附在OD表的某一列，形式就如同8-9-10-11这样。比如说，珠江新城到科韵路的OD对，其有效路径在有效路径集合这张表的第63680–63689行，到时候如果要匹配这个OD，就直接在有效路径集合的第63680–63689行进行匹配并计算，应该可以减少在循环上浪费的一些不必要的时间。3就是打算行人进站量采取3分钟粒度。
之后的一些其他改进到时候再跟您详细说明。以上就是对程序的一些想法，见笑了。
_1234567891.unknown
_1234567892.unknown
_1234567893.unknown
_1234567890.unknown
travel
T
trans
N
trans
T
angle
C