计数器达到上限后,有的规则回到低值,有的规则停在上限。下限以下的处理也一样重要,同一串增减操作会因规则不同得到完全不同的轨迹。
把数值范围明确设为零至二百五十五。回绕模型在每次加减后对二百五十六取非负余数;饱和模型则把每一步结果限制在上下限内。两者从同一个初值开始,输入增加量允许为负。
共同初值为241,逐次增加量由表格列出。回绕取余使用零至二百五十五的非负表示。
增加量 | 回绕前临时值 | 回绕后 | 饱和前临时值 | 饱和后 -199 | 42 | 42 | 42 | 42 91 | 133 | 133 | 133 | 133 188 | 321 | 65 | 321 | 255 309 | 374 | 118 | 564 | 255 -169 | -51 | 205 | 86 | 86 -94 | 111 | 111 | -8 | 0 239 | 350 | 94 | 239 | 239 172 | 266 | 10 | 411 | 255 277 | 287 | 31 | 532 | 255 88 | 119 | 119 | 343 | 255 -157 | -38 | 218 | 98 | 98 -167 | 51 | 51 | -69 | 0 -58 | -7 | 249 | -58 | 0 104 | 353 | 97 | 104 | 104 -138 | -41 | 215 | -34 | 0 -10 | 205 | 205 | -10 | 0 只在最终合计后处理一次的饱和值为255,它不一定等于逐步饱和结果。
表格中的编号只标识当前例子的元素,不应把对象身份、数组下标与计算数值混为一谈。阅读时先核对输入和边界,再沿记录检查每一步;空结果表示规则下没有可用项,并不是默认返回数值零。
每一步都要应用规则,不能把所有增加量合计后只处理一次,尤其是饱和会丢掉超出边界的部分。表中同时列出处理前的临时结果与处理后的状态,便于定位差异。
这里描述的是两个自定义数学模型,不是在承诺某种编程语言对所有整数类型都这样运行。实际实现必须确认类型、转换和溢出约定;游戏数值规则也应由设计决定,而不是意外依赖存储细节。
练习时先独立复算一小段,再检查整体结果是否满足文中条件。遇到差异应保留中间记录并定位第一处不一致,而不是只调整最后答案。更换输入或操作规则后,需要重新计算,原记录只对这一例负责。