可能导致浮点数突然偏离 1 位而没有算术变化的原因

在不修改任何类型的算术的情况下,我做了一个有点大的重构更改,我设法以某种方式更改了我的程序(基于代理的模拟系统)的输出。输出中的各种数字现在都偏离了微不足道的量。检查表明,这些数字在最不重要的位上相差1位。

例如,24.198110084326416 将变为 24.19811008432642。每个数字的浮点表示形式为:

24.198110084326416 = 0 10000000011 1000001100101011011101010111101011010011000010010100
24.19811008432642  = 0 10000000011 1000001100101011011101010111101011010011000010010101

其中,我们注意到最低有效位是不同的。

我的问题是,当我没有修改任何类型的算术时,我怎么能引入这个变化?更改涉及通过删除继承来简化对象(其超类因不适用于此类的方法而膨胀)。

我注意到输出(在模拟的每个价格变动时显示某些变量的值)有时会关闭,然后对于另一个价格变动,数字符合预期,只是在下一个价格变动中再次关闭(例如,在一个代理上,其值在价格变动 57 - 83 上表现出这个问题,但对于价格变动 84 和 85,则与预期一样, 只是为了勾选86而再次关闭)。

我知道我们不应该直接比较浮点数。当仅将输出文件与预期输出进行比较的集成测试失败时,会注意到这些错误。我可以(也许应该)修复测试来解析文件,并将解析的替身与一些epsilon进行比较,但我仍然很好奇为什么会引入这个问题。

编辑:

引入问题的最小变化差异:

diff --git a/src/main/java/modelClasses/GridSquare.java b/src/main/java/modelClasses/GridSquare.java
index 4c10760..80276bd 100644
--- a/src/main/java/modelClasses/GridSquare.java
+++ b/src/main/java/modelClasses/GridSquare.java
@@ -63,7 +63,7 @@ public class GridSquare extends VariableLevel
    public void addHousehold(Household hh)
    {
        assert household == null;
-       subAgents.add(hh);
+       neighborhood.getHouseholdList().add(hh);
        household = hh;
    }

@@ -73,7 +73,7 @@ public class GridSquare extends VariableLevel
    public void removeHousehold()
    {
        assert household != null;
-       subAgents.remove(household);
+       neighborhood.getHouseholdList().remove(household);
        household = null;
    }

diff --git a/src/main/java/modelClasses/Neighborhood.java b/src/main/java/modelClasses/Neighborhood.java
index 834a321..8470035 100644
--- a/src/main/java/modelClasses/Neighborhood.java
+++ b/src/main/java/modelClasses/Neighborhood.java
@@ -166,9 +166,14 @@ public class Neighborhood extends VariableLevel
    World world;

    /**
+    * List of all grid squares within the neighborhood.
+    */
+   ArrayList<VariableLevel> gridSquareList = new ArrayList<>();
+
+   /**
     * A list of empty grid squares within the neighborhood
     */
-   ArrayList<GridSquare> emptyGridSquareList;
+   ArrayList<GridSquare> emptyGridSquareList = new ArrayList<>();

    /**
     * The neighborhood's grid square bounds
@@ -836,7 +841,7 @@ public class Neighborhood extends VariableLevel
     */
    public GridSquare getGridSquare(int i)
    {
-       return (GridSquare) (subAgents.get(i));
+       return (GridSquare) gridSquareList.get(i);
    }

    /**
@@ -865,7 +870,7 @@ public class Neighborhood extends VariableLevel
    @Override
    public ArrayList<VariableLevel> getGridSquareList()
    {
-       return subAgents;
+       return gridSquareList;
    }

    /**
@@ -874,12 +879,7 @@ public class Neighborhood extends VariableLevel
    @Override
    public ArrayList<VariableLevel> getHouseholdList()
    {
-       ArrayList<VariableLevel> list = new ArrayList<VariableLevel>();
-       for (int i = 0; i < subAgents.size(); i++)
-       {
-           list.addAll(subAgents.get(i).getHouseholdList());
-       }
-       return list;
+       return subAgents;
    }

不幸的是,我无法创建一个小的,可编译的示例,因为我无法在程序之外复制此行为,也无法将这个非常大且纠缠不清的程序缩小到大小。

至于正在做什么样的浮点运算,没有什么特别令人兴奋的。大量的加法,乘法,自然对数和幂(几乎总是以e为底)。后两者是使用标准库完成的。随机数在整个程序中使用,并且与正在使用的框架中包含的随机一起生成(Repast)。

大多数数字在1e-3到1e5的范围内。几乎没有非常大或非常小的数字。Infinity和NaN在许多地方使用。

作为一个基于代理的模拟系统,许多公式被重复应用于模拟涌现。评估的顺序非常重要(因为许多变量取决于首先被评估的其他变量 - 例如,为了计算BMI,我们需要首先计算饮食和有氧状态)。变量的先前值在许多计算中也非常重要(因此这个问题可以在程序的早期某个地方引入,并在整个程序的其余部分进行)。


答案 1

浮点表达式的计算可能有所不同,以下是几种方法:

(1) 浮点处理器具有“当前舍入模式”,这可能导致结果在最低有效位上有所不同。您可以进行可以获取或设置当前值的调用:舍入为零、∞或 +∞。

(2)听起来严格fp与C中的FLT_EVAL_METHOD有关,后者指定了中间计算中使用的精度。有时,新版本的编译器将使用与旧版本不同的方法(我被那个方法咬了)。{0,1,2} 分别对应于 {单精度、双精度、扩展} 精度,除非被更高精度的操作数覆盖。

(3)就像不同的编译器可以有不同的默认浮点求值方法一样,不同的机器可以使用不同的浮点求值方法。

(4) 单精度 IEEE 浮点运算定义明确、可重复且独立于机器。双精度也是如此。我已经(非常小心地)编写了跨平台浮点测试,这些测试使用SHA-1哈希来检查计算的位精确性!但是,在 FLT_EVAL_METHOD=2 的情况下,扩展精度用于中间计算,中间计算使用 64 位、80 位或 128 位浮点运算以各种方式实现,因此如果在中间计算中使用扩展精度,则很难获得跨平台和跨编译器的可重复性。

(5)浮点算术不是结合的,即

(A + B) + C ≠ A + (B + C)

因此,编译器不允许对浮点数的计算进行重新排序。

(6) 操作顺序很重要。以尽可能高的精度计算一大组数字之和的算法是将它们相加以递增的数量级。另一方面,如果两个数字在幅度上相差足够大

B < (A * epsilon)

然后将它们相加是一个禁忌:

A + B = A

答案 2

由于 strictfp 已被删除,我将提供一个想法。

某些版本的Repast有/有错误,某些随机数被错误地生成*。

即使将随机种子设置为相同的值,由于 ArrayList 是在代码中的不同点创建和使用,因此您可能以不同的顺序对其中的代理执行操作。如果您有任何具有随机优先级的计划方法,则尤其如此。如果您使用getAgentList()或类似工具来填充子代理列表,情况也是如此。实际上,您可以生成一个随机数(/order),该随机数(/order)位于您为其设置种子的RNG之外。

如果执行顺序略有不同,这可以解释一个步骤的对应关系,而在其他步骤中看到这个微小的差异。

我遇到过这种情况,并且在调试时与您的报告有类似的头痛。如果您能提供它们,很乐意更详细地介绍它们。


*了解您正在使用哪个版本将有很大帮助(我知道我不应该在答案中要求澄清,但还没有让代表发表评论)。从您链接的API来看,我认为您使用的是旧的Repast 3 - 我使用Simphony,但答案可能仍然适用。