在以下示例中，是否可能出现除以0（或无穷大）的情况？
public double calculation(double a, double b)
{
if (a == b)
{
return 0;
}
else
{
return 2 / (a - b);
}
}
通常情况下，这是不可能的。但是如果a和b非常接近，由于计算精度的原因，(a-b)的结果可能会为0吗？
请注意，这个问题是针对Java的，但我认为它适用于大多数编程语言。
a - b永远不等于0。这是因为Java要求支持非规范化数字的IEEE 754浮点运算。来自spec：
如果FPU使用denormalized numbers，则减去不相等的数字永远不会产生零（与乘法不同），也请参见this question。特别地，Java编程语言需要支持IEEE 754非规范化浮点数和渐进式下溢，这使得证明特定数值算法的理想属性更加容易。如果计算结果是非规范化数字，则浮点运算不会“刷到零”。
话虽如此，对于表达式2 / (a - b)来说，它有可能溢出，例如当a = 5e-308和b = 4e-308时。
(a,b) = (3,1) => 2/(a-b) = 2/(3-1) = 2/2 = 1。至于IEEE浮点数是否正确，我不知道。 - Cole Tobin作为解决方法，以下方案如何？
public double calculation(double a, double b) {
double c = a - b;
if (c == 0)
{
return 0;
}
else
{
return 2 / c;
}
}
这样一来，您就不会在任何语言上依赖IEEE的支持。
a=b，你不应该返回 0。在 IEEE 754 中，除以 0 会得到无穷大而不是异常。你正在回避这个问题，所以返回 0 就像是一个等待发生的错误。考虑一下 1/x + 1。如果 x=0，结果将为 1，而不是正确的值：无穷大。 - Cole Tobin0 并不是问题的关键，这就是提问者在问题中所做的。你可以在代码块的那部分放置一个异常或者适当的内容来处理这种情况。如果你不喜欢返回 0，那应该批评问题本身。当然，像提问者一样做并不值得回答被点踩。这个问题与给定函数完成后的进一步计算无关。你只知道程序要求返回 0。 - jpmc26a - b 的值是什么，你都不会得到一个除以零的结果，因为浮点数除以0不会抛出异常，而是返回无穷大。a == b 为真，则唯一的可能是 a 和 b 包含了完全相同的二进制位。 如果它们只是最低有效位不同，它们之间的差别将不是0。a和b都是Double.NaN，则您将执行else语句，但由于NaN - NaN也返回NaN，因此您不会除以0。这里没有可能会发生除以零的情况。
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)。这意味着结果适用于所有可能的舍入模式（共五种）。结果还包括所涉及的任何变量可能是 NaN 或无穷大的可能性。
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。
当除法的结果太大无法存储在double类型中时，即使分母不为零，也会返回无穷大。
有了IEEE 754，几乎可以保证。C或C++编译器允许使用比所需精度更高的操作。因此，如果a和b不是变量而是表达式，则(a + b) != c并不意味着(a + b) - c != 0，因为a + b可能会被计算两次，一次精度更高，一次不高。
许多浮点单元可以切换到不返回非规格化数字的模式，而是用0替换它们。在这种模式下，如果a和b是微小的规范化数字，其差异小于最小的规范化数字但大于0，则a！= b也不能保证a == b。
“永远不要比较浮点数”是灵异信仰式的编程。在那些奉行“你需要一个epsilon”的人中，大多数人都不知道如何正确选择epsilon。
我可以想到一种情况，你也许能够导致这种情况发生。这里举一个十进制的类比实例 - 当然，在二进制下会更容易发生。
浮点数以科学计数法存储 - 也就是说，不是看到35.2，被存储的数字更像是3.52e2。
为了方便起见，想象一下我们有一个在十进制下运行并具有3位精度的浮点单元。当你从10.0中减去9.99时会发生什么？
1.00e2-9.99e1
将每个值移动到相同的指数
1.00e2-0.999e2
四舍五入保留3个数字
1.00e2-1.00e2
糟糕！
最终是否会发生此类情况取决于FPU设计。由于双精度指数范围非常大，硬件必须在某个时间点内部进行舍入，但在上述情况下，只要内部多保存1位有效数字就可以避免任何问题。
strictfp没有启用，计算可能会产生值，这些值对于double来说太小，但适合于扩展精度浮点值。 - supercat除以零是未定义的，因为正数趋近于无穷大的极限，负数趋近于负无穷大。
由于没有语言标签，不确定这是C++还是Java。
double calculation(double a, double b)
{
if (a == b)
{
return nan(""); // C++
return Double.NaN; // Java
}
else
{
return 2 / (a - b);
}
}
if ((first >= second - error) || (first <= second + error)
abs(first - second) < error（或者 <= error）更加简洁易懂。 - glglgl