为什么 2 个浮点数之间的这种简单划分不适用于 Java？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/2714003/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Why does this simple division between 2 floats not work with java?
提问by user323186
System.out.println((26.55f/3f));
or
或者
System.out.println((float)( (float)26.55 / (float)3.0 ));
etc.
等等。
returns the result 8.849999. not 8.85 as it should.
返回结果 8.849999。不是应该的 8.85。
Can anyone explain this or should we all avoid using floats?
任何人都可以解释这一点还是我们都应该避免使用浮点数？
回答by Michael Borgwardt
What Every Programmer Should Know About Floating-Point Arithmetic:
Q: Why don't my numbers, like 0.1 + 0.2 add up to a nice round 0.3, and instead I get a weird result like 0.30000000000000004?
A: Because internally, computers use a format (binary floating-point) that cannot accurately represent a number like 0.1, 0.2 or 0.3 at all.
问：为什么我的数字（例如 0.1 + 0.2）加起来不是很好的整数 0.3，而是得到一个奇怪的结果，例如 0.30000000000000004？
答：因为在内部，计算机使用的格式（二进制浮点数）根本无法准确表示 0.1、0.2 或 0.3 之类的数字。
In-depth explanations at the linked-to site
链接站点上的深入解释
回答by Donut
Take a look at Wikipedia's article on Floating Point, specifically the Accuracy Problemssection.
看看维基百科关于浮点的文章，特别是精度问题部分。
The fact that floating-point numbers cannot precisely represent all real numbers, and that floating-point operations cannot precisely represent true arithmetic operations, leads to many surprising situations. This is related to the finite precision with which computers generally represent numbers.
浮点数无法精确表示所有实数，并且浮点运算无法精确表示真正的算术运算，这一事实导致了许多令人惊讶的情况。这与计算机通常表示数字的有限精度有关。
The article features a couple examples that should provide more clarity.
这篇文章提供了几个示例，应该会提供更清晰的信息。
回答by Alex Martelli
Explaining is easy: floating point is a binary format and so can only represent exactly values that are an integer multiple of 1.0 / (2 to the Nth power)for some natural integer N. 26.55does not have this property, therefore it cannot be represented exactly.
解释很简单：浮点数是一种二进制格式，因此只能准确表示1.0 / (2 to the Nth power)某些自然整数的整数倍的值N。 26.55不具有此属性，因此无法准确表示。
If you need exact representation (e.g. your code is about accounting and money, where every fraction of a cent matters), then you must indeed avoid floats in favor of other types that do guarantee exact representation of the values you need (depending on your application, for example, just doing all accounting in terms of integer numbers of cents might suffice). Floats (when used appropriately and advisedly!-) are perfectly fine for engineering and scientific computations, where the input values are never "infinitely precise" in any case and therefore the computationally cumbersome burden of exact representation is absolutely not worth carrying.
如果您需要精确的表示（例如，您的代码是关于会计和金钱的，其中每一分钱都很重要），那么您确实必须避免使用浮点数来支持其他类型，这些类型可以保证您需要的值的精确表示（取决于您的应用程序） ，例如，仅根据整数美分进行所有会计处理就足够了）。浮点数（如果使用得当且谨慎！-）非常适合工程和科学计算，其中输入值在任何情况下都永远不会“无限精确”，因此精确表示的计算繁琐负担绝对不值得承担。
回答by Williham Totland
Well, we should all avoid using floats wherever realistic, but that's a story for another day.
好吧，我们都应该避免在任何现实的地方使用花车，但这是另一天的故事。
The issue is that floating point numbers cannot exactly represent most numbers we think of as trivial in presentation. 8.850000 probably cannot be represented exactly by a float; and possibly not by a double either. This is because they aren't actuallydecimal numbers; but a binary representation.
问题是浮点数不能完全代表我们认为在演示中微不足道的大多数数字。8.850000 可能无法用浮点数准确表示；也可能不是双倍。这是因为它们实际上不是十进制数；但二进制表示。
