C 这个int到float的转换是怎么回事，为什么不准确？

所以我基本上得到了这个代码

#include <stdio.h>

int main()
{
    int n = 0x7fffffff;
    float f = n;

    printf("%d\n", n);
    printf("%f\n", f);

    n = 0x00ffffff;
    f = n;

    printf("%d\n", n);
    printf("%f", f);
}

---

为什么是前两个数字之间的差异，而不是后两个数字之间的差异。我认为任何整数都可以用c中的任何浮点表示。为什么会发生这种情况？

不幸的是，你想错了

在具有32位整数和32位浮点的典型实现上，很明显，浮点不能完全包含所有整数，因为它的一些位必须用于指数，才能使其成为浮点

如果您的平台与IEEE-754兼容，并且您的浮点是单精度的，那么具体来说，它会如下所示：

• 1位符号
• 8位指数
• 24位1-有效位

这意味着所有高达24位的整数都可以精确表示，之后，某些数字的精度必然会降低

在相同的假设下，一个double将保存所有32位整数，因为一个double具有53位的精度

参考资料：

---

1：仅存储23位，但对于常规数字，顶部位始终被视为1。这意味着，如果顶部位需要为零，则整个内容将向左移动，并且指数减小。这使我们获得了不需要存储的额外精度。

不幸的是，您想错了

在具有32位整数和32位浮点的典型实现上，很明显，浮点不能完全包含所有整数，因为它的一些位必须用于指数，才能使其成为浮点

如果您的平台与IEEE-754兼容，并且您的浮点是单精度的，那么具体来说，它会如下所示：

• 1位符号
• 8位指数
• 24位1-有效位

这意味着所有高达24位的整数都可以精确表示，之后，某些数字的精度必然会降低

在相同的假设下，一个double将保存所有32位整数，因为一个double具有53位的精度

参考资料：

---

1：仅存储23位，但对于常规数字，顶部位始终被视为1。这意味着，如果顶部位需要为零，则整个内容将向左移动，并且指数减小。这为我们提供了一个不需要存储的额外精度。

不是每个数字都可以表示为

float

。第一个不是。任何整数都可以用c中的任何浮点表示-这不是真的

float

可能由与

int

相同的位数表示，但其范围更广，包括小数。所以通过，它不能代表所有的整数。“我认为任何整数都可以用c中的任何浮点表示。”。现在你知道这是不正确的。浮动精度有限。我建议阅读IEEE 754标准，了解浮点数如何工作的规范。整数的可能副本为32位，尾数和指数的浮点值均为32位。因此，单凭皮杰恩霍尔原理，就会有许多整数不能精确地表示为浮点数。您可以将所有32位整数转换为一个双精度整数。True，但可能是OP的情况。并非每个数字都可以表示为

float

。第一个不是。任何整数都可以用c中的任何浮点表示-这不是真的

float

可能由与

int

相同的位数表示，但其范围更广，包括小数。所以通过，它不能代表所有的整数。“我认为任何整数都可以用c中的任何浮点表示。”。现在你知道这是不正确的。浮动精度有限。我建议阅读IEEE 754标准，了解浮点数如何工作的规范。整数的可能副本为32位，尾数和指数的浮点值均为32位。因此，单凭皮杰恩霍尔原理，就会有许多整数不能精确地表示为浮点数。您可以将所有32位整数转换为一个双精度整数。是的，但可能是OP的情况。谢谢您的回答，困惑=消失了。不完全是这样。

float

范围内的任何大小整数都可以精确编码为32位

float

，前提是其所有

1

位都包含在24位的范围内。是的，有些整数仍然可以表示，但不是全部。如果你能很有说服力地提出修改意见，请随意提出。编辑：为了更精确，我稍微修改了措辞。例如

uint64\u t v=0xFFFFFF0000000000

可以用

float

精确表示。事实上，尽管有一些

int

s可以精确表示为

float

s，但它们占所有

int

s（32位/32位情况）的不到1%。碰巧的是，我们最经常特别关心的那些——主要是小的——不成比例地出现在有代表性的问题中。谢谢你的回答，困惑=消失了。不是完全消失了。

float

范围内的任何大小整数都可以精确编码为32位

float

，前提是其所有

1

位都包含在24位的范围内。是的，有些整数仍然可以表示，但不是全部。如果你能很有说服力地提出修改意见，请随意提出。编辑：为了更精确，我稍微修改了措辞。例如

uint64\u t v=0xFFFFFF0000000000

可以用

float

精确表示。事实上，尽管有一些

int

s可以精确表示为

float

s，但它们占所有

int

s（32位/32位情况）的不到1%。碰巧的是，我们最经常特别关心的那些——主要是小的——在代表性的作品中不成比例。

>     2147483647                                                                             
>     2147483648.000000                                                                      
>     16777215                                                                               
>     16777215.000000