我正在尝试使用 Excel 中的 Match 函数。如图所示，我尝试使用 Match 函数查找数字 27.04。但是，即使该数字显然存在，该函数也会返回 #NA。当我在包含函数的单元格上使用 Match 时，通常会出现此问题。有人能解释一下发生了什么吗？谢谢
附图：
答案1
这是 Excel 中的一个已知问题。由于数字在内存中的存储方式，匹配浮点数一直是 Excel 的一个问题。目前有几个选项：
不要将您要查找的值硬编码到公式中，而是使用单元格引用。例如，在单元格 G6 中输入 27.04 并使用公式
=MATCH(G6,$E$5:$E$13,0)。这是我个人推荐的选项。对 E 列中的计算结果进行四舍五入。使用 ROUND 函数将结果四舍五入到小数点后两位，这样就可以实现精确匹配。所以，
=ROUND($C5*$D5,2)。如果您确实需要，这允许您在公式中使用硬编码值。
答案2
这一切都令人着迷，但事实证明值的差异在小数点后第 15 位...而整数部分是两位数意味着 Excel 将显示的内容，即使在数字格式框/功能中也恰好是小数点后 13 位。
这些都是零，所以我们看到的是“27.0400000000000”，但实际上该值高于3.5527136788005E-15真正的“27.04”：27.0400000000000035527136788005。
Excel 使用的位数总是比它返回单元格值的数字多得多。据说是 27-28 位数字，具体取决于符号，但总是会截断值以将其作为结果放在单元格内。
显然，现在至少在 2209 版中，它提供了所有精度。算出上面的数字，它是 28 个有效数字。我仅F9在以下公式的单元格中使用时才得到该数字：
=MATCH( (C1-C4), $C$1:$C$10, 0)
它确实使用了(C1-C4)正确的方法（在我考虑改变MATCH的最后一个参数之后），但F9无论匹配结果如何，都会使用来计算上面的余数。
我想说的是，我以前从来没有这样做过，所以我不知道这是否是新鲜事，或者我们是否可以在几十年内恢复所有额外的准确性...如果我们一直都能做到的话，那该有多好。
然而，当我好奇 Excel 是否采取了新方法来显示不完美的二进制-十进制结果时，我以为这种情况正在发生（实际上类似于 27.0400000000002，但 Excel 意识到了这个问题（最终）并无论如何都“完美”地显示了它。而且它可能还处于早期阶段，尚未完全适应所有功能，以及通常的情况。但如果是这样的话，那就非常有趣了。但不是那样，只是……Excel 内部使用的全部值的惊人规定。
哪一个更大！即使一直以来都是这样，因为这个想法是通过 Excel 对放置在单元格中的实际值进行四舍五入而丢失的。
因此，它是我们几十年的宿敌，毫无疑问，而舍入的想法，比如Werff的答案或任何其他舍入方法，都是肯定可行的方法。
不管怎样，我们现在可以获得最多 28 位有效数字。像上面一样。
顺便说一句，这是肯定的，不仅仅是因为我（声称我做到了)，而是因为：
你也可以使用我使用的方法。如果不是这样，它根本就不应该存在。而且，
如果差值出现在第 17 位有效数字处，那么如果它像过去一样（或者至少每个人都确信它是这样的），那么这个差值就不会存在，从而导致计算结果不同于输入的“27.04”...它会在第 15 位有效数字处被截断并永远消失，所以 OP 永远不会有这个问题。