Java 中的双重算术和相等

发布于 2024-12-02 20:58:26 字数 428 浏览 2 评论 0原文

这是一个奇怪的地方(至少对我来说)。这个例程打印 true:

double x = 11.0;
double y = 10.0;
if (x-y == 1.0) {
    // print true
} else {
    // print false
}

但这个例程打印 false:

double x = 1.1;
double y = 1.0;
if (x-y == 0.1) {
    // print true
} else {
    // print false
}

有人愿意解释一下这里发生了什么吗?我猜测这与将 int 冒充为 float 的整数运算有关。另外,是否还有其他碱基(10 除外)具有此属性?

Here's an oddity (to me, at least). This routine prints true:

double x = 11.0;
double y = 10.0;
if (x-y == 1.0) {
    // print true
} else {
    // print false
}

But this routine prints false:

double x = 1.1;
double y = 1.0;
if (x-y == 0.1) {
    // print true
} else {
    // print false
}

Anyone care to explain what's going on here? I'm guessing it has something to do with integer arithmetic for ints posing as floats. Also, are there other bases (other than 10) that have this property?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

萌吟 2024-12-09 20:58:26

1.0 具有精确的二进制表示形式。 0.1 则不然。

也许您会问为什么 0.1 不存储为 1 的尾数和 -10 的指数?但事实并非如此。它不是十进制数加指数,而是二进制数。所以“乘以10”并不是一件自然的事情。

抱歉,也许最后一部分不清楚。最好将指数视为位的移位。任何位的移位都不会将像 0.1(十进制)这样的无限序列转换为有限序列。

1.0 has an exact binary representation. 0.1 does not.

perhaps you are asking why 0.1 is not stored as a mantissa of 1 and an exponent of -10? but that's not how it works. it's not a decimal number plus an exponent, but a binary number. so "times 10" is not a natural thing.

sorry, maybe the last part is unclear. it's better to think of the exponent as a shift of bits. no shift of bits will convert an infinite sequence like 0.1 (decimal) into a finite one.

被翻牌 2024-12-09 20:58:26

编辑
安德鲁纠正了我。谢谢你!

Java 遵循 IEEE 754,基数为 2,因此无法正确表示 0.1(约为 0.1000000000000000055511151231257827021181583404541015625 或IEEE 中的 1.1001100110011001100110011001100110011001100110011010 * 2^-4),您可以根据 double 的二进制表示形式找到它(位 63 = 符号,位 62- 52 = 指数和位51-0 是尾数):

long l = Double.doubleToLongBits(0.1);
System.out.println(Long.toBinaryString(l));

我只是被结果冲昏了头脑,我想了一下 Java 中的浮点数是以 10 为基数的,在这种情况下,有可能代表0.1就好了。

现在,希望一劳永逸地解决问题,接下来会发生什么:

BigDecimal bigDecimal1 = new BigDecimal(0.1d);
BigDecimal bigDecimal2 = new BigDecimal(1.1d - 1.0);
BigDecimal bigDecimal3 = new BigDecimal(1.1d);
BigDecimal bigDecimal4 = new BigDecimal(1.0d);
System.out.println(bigDecimal1.doubleValue());
System.out.println(bigDecimal2.doubleValue());
System.out.println(bigDecimal3.doubleValue());
System.out.println(bigDecimal4.doubleValue());
System.out.println(bigDecimal1);
System.out.println(bigDecimal2);
System.out.println(bigDecimal3);
System.out.println(bigDecimal4);

输出:

0.1
0.10000000000000009
1.1
1.0
0.1000000000000000055511151231257827021181583404541015625
0.100000000000000088817841970012523233890533447265625
1.100000000000000088817841970012523233890533447265625
1

那么会发生什么? 1.1 - 1.0 相当于:
1.100000000000000088817841970012523233890533447265625 - 1(Java无法精确表示1.1) 0.100000000000000088817841970012523233890533447265625 这与 Java 内部表示 0.1 的方式不同(0.1000000000000000055511151231257827021181583404541015625)

如果您想知道为什么减法结果显示为 0.100000000000000009 并且显示“0.1”是,看看这里

Edit
I stand corrected by Andrew. Thank you!

Java follows IEEE 754 with a Base of 2, so it cannot represent 0.1 correctly (it is aprox. 0.1000000000000000055511151231257827021181583404541015625 or 1.1001100110011001100110011001100110011001100110011010 * 2^-4 in IEEE) which you can find out based on the binary representation of the double like this (bit 63 = sign, bits 62-52 = exponent and bits 51-0 being the mantissa):

long l = Double.doubleToLongBits(0.1);
System.out.println(Long.toBinaryString(l));

I just got carried away by the results and I thought for a moment that the floats in Java are working with a Base of 10 in which case it would have been possible to represent 0.1 just fine.

And now to hopefully clear the things once and for all, here's what goes on:

BigDecimal bigDecimal1 = new BigDecimal(0.1d);
BigDecimal bigDecimal2 = new BigDecimal(1.1d - 1.0);
BigDecimal bigDecimal3 = new BigDecimal(1.1d);
BigDecimal bigDecimal4 = new BigDecimal(1.0d);
System.out.println(bigDecimal1.doubleValue());
System.out.println(bigDecimal2.doubleValue());
System.out.println(bigDecimal3.doubleValue());
System.out.println(bigDecimal4.doubleValue());
System.out.println(bigDecimal1);
System.out.println(bigDecimal2);
System.out.println(bigDecimal3);
System.out.println(bigDecimal4);

Outputs:

0.1
0.10000000000000009
1.1
1.0
0.1000000000000000055511151231257827021181583404541015625
0.100000000000000088817841970012523233890533447265625
1.100000000000000088817841970012523233890533447265625
1

So what happens? 1.1 - 1.0 is equivalent to:
1.100000000000000088817841970012523233890533447265625 - 1 (Java can't represent 1.1 precisely) which is 0.100000000000000088817841970012523233890533447265625 and this is different than the way Java represent 0.1 internally (0.1000000000000000055511151231257827021181583404541015625)

If you're wondering why the result of the subtraction is being displayed as 0.10000000000000009 and the "0.1" is displayed as it is, have a look over here

硪扪都還晓 2024-12-09 20:58:26

这一直出现在货币计算中。如果您需要精确的数字表示,请使用 BigDecimal当然,这是不具备硬件支持性能的成本。

This comes up in currency calculations all the time. Use BigDecimal if you need exact numerical representation at the cost of not having hardware enabled performance, of course.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文