重复评论中所说的话。32位版本的“4319.9997”实际上更接近于“4319.9995”。当numpy/Python/C试图将“4319.9998”从64位浮点数转换为32位浮点数时，只有两个选项是“4319.9995”或“4320.0”，而“4320.0”更接近，因此它会向上舍入。我不能说这是怎么回事，但它使一些意义给我。

原始答案：

我不能说我完全理解我要回答的问题，但有些是有道理的。我认为这可以归结为Python（或C或其他东西）如何将字符串字面量转换为32位浮点数。
二进制打印函数来自：
https://stackoverflow.com/a/16444778/433202

import struct
def binary(num):
    return ''.join('{:0>8b}'.format(c) for c in struct.pack('!f', num))

并使用它将数字打印为32位IEEE浮点数：

In [62]: binary(4319.9997)
Out[62]: '01000101100001101111111111111111'

In [63]: binary(4319.9998)
Out[63]: '01000101100001110000000000000000'

因此，0表示符号，10001011表示指数部分，00001101111..表示小数有效位部分。
所以当我输入的字符串字面量被转换成双精度数时，它达到了某个阈值，小数部分被加了一个1，这将所有的位都滚到了有效数的整数部分。
对我来说，这整件事的最大误解/误解是，当我被告知将浮点数转换为int将“截断”数字的小数部分时，我假设它是在以10为基数进行的，但它（C？）实际上是在基数2中进行的。这是显而易见的道理，但我从来没有想过，直到这个问题。
我仍然不明白的部分是，为什么从我输入的浮点字符串字面量“4319.9998”转换到下一个数字（+1）。为什么不接受精度问题并将其保持为与“4319.9997”相同的值？我做了一个64位（双精度）版本的二进制函数，当我打印出这两个版本的数字时：

In [91]: binary64(4319.9997)
Out[91]: '0100000010110000110111111111111111101100010101101101010111010000'

In [92]: binary64(4319.9998)
Out[92]: '0100000010110000110111111111111111110010111001001000111010001010'

如果你对64位浮点表示的位数进行计数并将其分开，两个值在正负号的“整数”部分之后都有很多1（在将.移位到指数位之后），所以我不确定为什么一个会被舍入而另一个不会。