是否可以通过减去两个不相等的浮点数来获得0？

在下面的示例中是否可以除以0（或无穷大）？

public double calculation(double a, double b)
{
     if (a == b)
     {
         return 0;
     }
     else
     {
         return 2 / (a - b);
     }
}

在正常情况下，当然不会。但是如果a和b非常接近，会由于计算精度而(a-b)导致结果0吗？

请注意，这个问题是针对Java的，但是我认为它将适用于大多数编程语言。

在Java中，a - b永远不等于0if a != b。这是因为Java要求IEEE 754浮点运算支持不规范的数字。从规格：

特别是，Java编程语言需要支持IEEE 754非规范化浮点数和渐进下溢，这使得更容易证明特定数值算法的理想特性。如果计算结果为非规范化数字，则浮点运算不会“刷新为零”。

如果FPU使用非正规数，则减去不等数永远不会产生零（与乘法不同），另请参见此问题。

对于其他语言，这取决于。例如，在C或C ++中，IEEE 754支持是可选的。

也就是说，表达式可能2 / (a - b)会溢出，例如使用a = 5e-308和b = 4e-308。

作为一种解决方法，该怎么办？

public double calculation(double a, double b) {
     double c = a - b;
     if (c == 0)
     {
         return 0;
     }
     else
     {
         return 2 / c;
     }
}

这样，您就不会依赖任何语言的IEEE支持。

不管的值如何，都不会除以零a - b，因为浮点除以0不会引发异常。它返回无穷大。

现在，唯一的a == b返回true的方法是if a和b包含完全相同的位。如果它们仅相差最低有效位，则它们之间的差将不会为0。

编辑：

正如Bathsheba正确评论的那样，有一些例外：

1. 假“本身不是数字比较”为假，但将具有相同的位模式。

2. -0.0被定义为将true与+0.0进行比较，并且它们的位模式不同。

因此，如果aand和bare Double.NaN，则将到达else子句，但由于NaN - NaN还返回NaN，所以不会被零除。

在任何情况下都不会发生被零除的情况。

该SMT求解 Z3支持精确IEEE浮点运算。让我们让Z3查找数字a，b这样a != b && (a - b) == 0：

(set-info :status unknown)
(set-logic QF_FP)
(declare-fun b () (FloatingPoint 8 24))
(declare-fun a () (FloatingPoint 8 24))
(declare-fun rm () RoundingMode)
(assert
(and (not (fp.eq a b)) (fp.eq (fp.sub rm a b) +zero) true))
(check-sat)

结果是UNSAT。没有这样的数字。

上面的SMTLIB字符串还允许Z3选择任意舍入模式（rm）。这意味着结果适用于所有可能的舍入模式（其中有五种）。结果还包括游戏中任何变量可能为NaNor无限的可能性。

a == b被实现为fp.eq质量，因此+0f与-0f比较相等。与零的比较也使用来实现fp.eq。由于问题旨在避免被零除，因此这是适当的比较。

如果相等测试时使用逐平等实施，+0f并-0f会是一个方法，使a - b零。这个答案的不正确的先前版本包含有关该情况的模式详细信息，以示好奇。

Z3 Online尚不支持FPA理论。使用最新的不稳定分支可获得此结果。可以使用.NET绑定来复制它，如下所示：

var fpSort = context.MkFPSort32();
var aExpr = (FPExpr)context.MkConst("a", fpSort);
var bExpr = (FPExpr)context.MkConst("b", fpSort);
var rmExpr = (FPRMExpr)context.MkConst("rm", context.MkFPRoundingModeSort());
var fpZero = context.MkFP(0f, fpSort);
var subExpr = context.MkFPSub(rmExpr, aExpr, bExpr);
var constraintExpr = context.MkAnd(
        context.MkNot(context.MkFPEq(aExpr, bExpr)),
        context.MkFPEq(subExpr, fpZero),
        context.MkTrue()
    );

var smtlibString = context.BenchmarkToSMTString(null, "QF_FP", null, null, new BoolExpr[0], constraintExpr);

var solver = context.MkSimpleSolver();
solver.Assert(constraintExpr);

var status = solver.Check();
Console.WriteLine(status);

使用Z3回答IEEE浮点问题是很好的，因为它是很难忽视的情况下（如NaN，-0f，+-inf），你可以问任意问题。无需解释和引用规范。您甚至可以问浮点数和整数的混合问题，例如“此特定int log2(float)算法正确吗？”。

提供的函数确实可以返回无穷大：

public class Test {
    public static double calculation(double a, double b)
    {
         if (a == b)
         {
             return 0;
         }
         else
         {
             return 2 / (a - b);
         }
    }    

    /**
     * @param args
     */
    public static void main(String[] args) {
        double d1 = Double.MIN_VALUE;
        double d2 = 2.0 * Double.MIN_VALUE;
        System.out.println("Result: " + calculation(d1, d2)); 
    }
}

输出为Result: -Infinity。

当除法的结果大到要存储在双精度数中时，即使分母非零，也将返回无穷大。

在符合IEEE-754的浮点实现中，每种浮点类型可以容纳两种格式的数字。一个（“归一化”）用于大多数浮点值，但是它可以表示的第二个最小的数字仅比最小的数字大一点点，因此，在相同的格式下它们之间的差异无法表示。另一种（“非规格化”）格式仅用于无法用第一种格式表示的非常小的数字。

有效处理非规范化浮点格式的电路成本很高，而且并非所有处理器都包含该格式。有些处理器都提供了非常小的数字既可以采用具有操作之间的选择是很多比其他值的操作速度较慢，或具有处理器简单地认为这是标准化的格式零过小的数。

Java规范暗示实现应该支持非规范化格式，即使在这样的机器上，这样做也会使代码运行得更慢。另一方面，某些实现可能会提供一些选项，以允许代码更快地运行，以换取对值稍作草率的处理，这在大多数情况下将变得无关紧要（在值太小而又无关紧要的情况下，进行计算所需的时间是重要的十倍，这可能会很烦人，因此在许多实际情况下，“清零”比“慢而精确”的算法有用。

在IEEE 754之前的较早时期，a！= b并不意味着ab！= 0很有可能反之亦然。这就是首先创建IEEE 754的原因之一。

使用IEEE 754 几乎可以保证。允许C或C ++编译器执行比所需精度更高的操作。因此，如果a和b不是变量而是表达式，则（a + b）！= c并不意味着（a + b）-c！= 0，因为a + b可以更精确地计算一次，而无需计算一次精度更高。

可以将许多FPU切换到不返回非规范化数字而将其替换为0的模式。在该模式下，如果a和b是微小的规范化数字，其差小于最小规范化数字但大于0，则a ！= b也不能保证a == b。

“绝不比较浮点数”是一种崇高的编程方式。在口头禅“您需要一个epsilon”的人中，大多数人都不知道如何正确选择该epsilon。

我可以想到一种情况，在这种情况下您可能会导致这种情况发生。这是一个以10为底的类似样本-实际上，这当然会以2为底。

浮点数或多或少以科学计数法存储-也就是说，与看到35.2相比，所存储的数字更像是3.52e2。

为了方便起见，请想象一下，我们有一个浮点数单元，以10为基数操作，精度为3位。如果从10.0中减去9.99，会发生什么？

1.00e2-9.99e1

移位以赋予每个值相同的指数

1.00e2-0.999e2

四舍五入至三位数

1.00e2-1.00e2

哦！

最终能否实现取决于FPU设计。由于双精度指数的取值范围非常大，因此硬件必须在某个时候进行内部取整，但是在上述情况下，内部仅增加1位数字就可以避免任何问题。

您不应该比较浮点数或双精度数是否相等。因为，您不能真正保证分配给float或double的数字是准确的。

要比较浮点数是否相等，您需要检查该值是否“足够接近”相同的值：

if ((first >= second - error) || (first <= second + error)

零除是不确定的，因为从正数开始的极限趋于无穷大，所以从负数开始的极限趋于负无穷大。

由于没有语言标签，因此不确定是C ++还是Java。

double calculation(double a, double b)
{
     if (a == b)
     {
         return nan(""); // C++

         return Double.NaN; // Java
     }
     else
     {
         return 2 / (a - b);
     }
}

核心问题是，当您使用“太多”的十进制数时，例如，当您处理不能以数值形式写入的double时，double的计算机表示形式（aka浮点数或数学语言中的实数）是错误的。 pi或1/3的结果）。

所以a == b不能用a和b的任何双精度值完成，当a = 0.333和b = 1/3时如何处理a == b？取决于您的操作系统，FPU，数字，语言还是0后的3，您将得到true或false。

无论如何，如果您在计算机上执行“双值计算”，则必须处理准确性，因此a==b必须要做的是absolute_value(a-b)<epsilon，而不是做，并且epsilon与您当时在算法中建模的相对。您不能为所有双重比较都提供一个epsilon值。

简而言之，当您键入a == b时，您将拥有一个数学表达式，该表达式无法在计算机上进行翻译（对于任何浮点数）。

PS：哼，我在这里回答的一切或多或少都来自其他人的回应和评论。

基于@malarres回复和@Taemyr评论，这是我的一点贡献：

public double calculation(double a, double b)
{
     double c = 2 / (a - b);

     // Should not have a big cost.
     if (isnan(c) || isinf(c))
     {
         return 0; // A 'whatever' value.
     }
     else
     {
         return c;
     }
}

我的意思是说：知道除法结果是nan还是inf的最简单方法实际上是执行除法。