路由评分计算方法在不同电脑输出结果差约36倍问题排查

你的CalculateScore方法在代码、输入文件完全一致的两台电脑上结果差约36倍，结合代码逻辑，重点排查以下几个核心方向：

1. 整数溢出导致的数值偏差 #

36倍的整倍数偏差大概率和数值溢出相关，尤其是当涉及大数值运算时：

• 若两台电脑分别运行32位和64位版本的程序，mDistances（如果是int[,]类型）、mOrders.duur（如果是int类型）这类字段在32位环境下可能触发溢出，导致计算值被截断或变为错误的小数值；64位环境则能正常处理大整数，最终结果就会出现倍数级差异。
• 检查mDistances、mOrders.duur的类型定义，以及文件中对应数值是否超出32位int的范围（-2147483648 到 2147483647）。

2. 字典访问的逻辑一致性问题 #

代码中通过mRoutes[wagen, dag, trip].mDictRoute[huidigeLocatieIndex].Item2获取下一个索引，完全依赖字典键的连续性和对应值的正确性：

• 字典的内部存储结构在不同.NET版本或系统架构下可能存在差异，若某台电脑上字典的键映射出现异常，会导致循环中累加的次数或数值出现偏差。
• 在两台电脑上打印mDictRoute的所有键值对，对比键的存在性、Item2的数值是否完全一致。

3. 数值解析的区域设置干扰 #

即使输入文件一致，两台电脑的区域设置可能影响数值解析逻辑：

• 比如文件中用.作为小数点，但某台电脑默认用,作为小数点，会导致数值被错误放大（如123.45被解析为12345），若同时叠加其他单位解析错误（如时间单位混淆），可能出现36倍的偏差。
• 检查文件解析代码是否指定了固定的文化信息（如CultureInfo.InvariantCulture），避免区域设置干扰。

4. 浮点类型转换的精度问题 #

代码最后返回score/60.0f，这里用float类型的60.0f和double类型的score运算：

• 虽然这通常不会直接导致36倍偏差，但如果score数值极大，float的精度不足可能引发意外截断；可以改为score/60.0（double类型）测试是否解决问题。

快速定位手段 #

在两台电脑上添加日志，打印以下关键中间值对比：

• 内层循环中每次累加的mDistances和mOrders.duur数值
• 外层三个循环（dag/wagen/trip）的实际执行次数
• penalty部分的累加值
• 最终score在除以60之前的原始数值

通过对比这些值，能快速定位偏差出现的具体环节。

内容的提问来源于stack exchange，提问作者Quinten1208