问题标签 [floating-point-precision]

我有一个数百位长的浮点值（如 pi - 3 的前 100 位），需要一种对其进行操作的方法。有什么方法可以存储和操作具有大量小数的浮点数并通过内置库保持很高的精度？c++中有没有类似python的十进制模块的东西？

我的算法正在计算单精度浮点运算的epsilon 。它应该在 1.1921e-007 左右。这是代码：

在调试模式下，它给出以下合理的输出（缩写）：

但是，当切换到发布模式时（无论有/无优化！），代码给出以下结果：

这对应于double precision的值。所以我假设，一些优化会导致对双精度值进行计算。在这种情况下，结果当然是错误的！

另外：只有在项目选项中以X86 Release 为目标时才会发生这种情况。同样：优化开/关无关紧要。我使用的是 64 位 WIN7，VS 2010 Ultimate，目标是 .NET 4.0。

什么可能导致这种行为？一些WOW问题？如何以可靠的方式绕过它？如何防止 CLR 生成使用双精度而不是单精度计算的代码？

注意：切换到“Any CPU”甚至“X64”作为平台目标是没有选择的——即使这里没有出现问题。但是我们有一些本地库，有不同版本的 32/64 位。所以目标必须是具体的。

我正在寻找一种能够在单精度和双精度之间进行转换的方法。一个例子是将 2 个整数相除并得到一个浮点结果。这怎么可能？

有一个关于 Python 中浮点数（和精度）的底层数据结构的问题：

似乎 b 和 c 的值取决于机器，它们是最接近目标值但不完全相同的数字。我受到监督，我们通过“打印”获得了“正确”的数字，有人告诉我这是因为打印“谎言”，而 Python 选择告诉我们真相，即准确显示它们存储的内容。

我的问题是：

1. 如何撒谎？例如，在一个函数中，我们取两个值并返回它们是否相同，如果小数位数（精度）未知，我怎么能有一个最好的猜测？像上面提到的b和c？有没有明确定义的算法来做到这一点？有人告诉我，如果我们涉及浮点计算，每种语言（C/C++）都会遇到这种问题，但是他们如何“解决”这个问题呢？

2. 为什么我们不能只存储实际数字而不是存储最接近的数字？是限制还是换取效率？

非常感谢约翰

所以我一直试图围绕浮点数中有效数字的数量与精度的相对损失之间的关系，但我似乎无法理解它。我之前正在阅读一篇文章，说要执行以下操作：

1. 设置一个浮点数为 2147483647。你会看到它的值实际上是 2147483648
2. 从浮点数中减去64，你会看到操作是正确的
3. 从浮点数中减去 65，你会看到你现在实际上有 2147483520，这意味着它实际上减去了 128。

那么当有 10 位有效数字时，为什么是 128 呢？我了解浮点数是如何存储的（1 位用于符号，8 位用于指数，23 位用于尾数）并且了解如果您假设所有整数都会自动找到浮点数据结构中的确切位置，您将如何失去精度，但我不知道不明白 128 是从哪里来的。我的直觉告诉我，我走在正确的轨道上，但我希望有人能够为我解决这个问题。

我最初认为可能的浮点数之间的距离是 2 ^ (n-1) 其中 n 是有效数字的数量，但这并不成立。

谢谢！

假设 a,b是_int64变量。需要以sqrt((long double)a)*sqrt((long double)b)高精度 80 位浮点计算。

例子。(__int64)(sqrt((long double)a)*sqrt((long double)a) + 0.5) != a在许多情况下应该如此。

哪个 win32 C/C++ 编译器可以管理 80 位浮点运算？

为什么 ColdFusion 中的数学运算似乎不受浮点数学问题的影响？拿下代码：

哪个输出

0.07

java.lang.Double

然而，当添加两个双打时，等效的 Java 代码会产生我所期望的：

由于浮动数学的现实（ http://download.oracle.com/docs/cd/E19957-01/806-3568/ncg_goldberg.html） ，这是我期望从 ColdFusion 看到的。

ColdFusion 是否在幕后做了一些“魔术”，还是我在这里看到了一个孤立的异常？

我知道基本数据类型，浮点类型（float，double）不能准确地保存一些数字。

然而，在将一些代码从 Matlab 移植到 Python (Numpy) 时，我发现计算上有一些显着差异，我认为它会回到精确度。

使用以下代码，对 500 维向量进行 z 归一化，其中只有前两个元素具有非零值。

MATLAB：

Python：

除了格式在 Python 中显示更多的数字之外，还有一个巨大的差异（恕我直言），超过 0.02

Python 和 Matlab 都使用 64 位数据类型 (afaik)。Python 使用 'numpy.float64' 和 Matlab 'double'。

为什么差异如此之大？哪一个更正确？

我正在打印来自 C++ 程序的一些数据，以由 ParaView 处理/可视化，但我遇到了浮点数问题。Paraview 支持 Float32 和 Float64 数据类型。Float64 相当于 double ，典型限制为 +/-1.7e +/- 308。但是，我的代码正在打印 6.5e-318 之类的数字。这会在读取数据时在 ParaView 中引发错误。我已经验证将这些小数四舍五入为零会使 ParaView 中的错误消失。我不确定为什么我有这样的“高精度”输出，可能是因为某些数字的存储精度比双精度高。例如，以下代码在我的系统上重现了相同的行为：

我的输出是：

我的系统是 Mac OS X Snow Leopard，我用 GCC 4.2和GCC 4.6 测试了上面的 flags-m32和（不确定这是否有用）。-m64-ffloat-store

实际上对我来说输出很好，但对 ParaView 来说不是。我只是想知道为什么我有这种差异。我很可能会忽略与浮点数相关的一些可能很重要的东西。您能否给我一些关于双打的输出/数值行为的线索？

这段小代码让我抓狂：

事实上，由于 IEEE 754 标准中浮点数的内部表示，我试图证明一个病态的案例。在 MacOs 或 windows 机器上，最终输出行将显示为：

周期 29 值：1.28084153156127500000e+13

但是在 Linux (Scientific Linux 5.4) 上，代码将毫无问题地运行。阅读我发现：

在 FreeBSD、NetBSD 和 OpenBSD 等 BSD 系统上，硬件双精度舍入模式是默认的，最大程度地兼容原生双精度平台。在 x86 GNU/Linux 系统上，默认模式是扩展精度（旨在提供更高的精度）。

在同一页上解释了GCC INTRO如何在 Linux 系统上启用双精度舍入，而不是如何在其他系统上使用扩展精度。这在 MacO 或 Windows 上可行吗？如何 ？