问题标签 [ieee-754]

当我在 32 位和 64 位环境下运行我的应用程序时，双倍大小有区别吗？

如果我没记错的话，32 位环境中的双精度将在 0 之后占用 16 位，而 64 位环境中的双精度将占用 32 位，对吗？

我正在做高精度的科学计算。在寻找各种效果的最佳表示时，我不断提出想要获得下一个更高（或更低）双精度数的理由。本质上，我想做的是在双精度的内部表示中的最低有效位上加一个。

困难在于 IEEE 格式并不完全统一。如果要使用低级代码并实际上将 1 添加到最低有效位，则生成的格式可能不是下一个可用的双精度。例如，它可能是一个特殊情况数，例如 PositiveInfinity 或 NaN。还有一些低于正常值的值，我不声称理解，但它们似乎具有与“正常”模式不同的特定位模式。

可以使用“epsilon”值，但我从未理解它的定义。由于 double 值的间距不均匀，因此不能将单个值添加到 double 以产生下一个更高的值。

我真的不明白为什么 IEEE 没有指定一个函数来获得下一个更高或更低的值。我不能成为唯一需要它的人。

有没有办法获得下一个值（没有某种尝试添加越来越小的值的循环）。

我需要评估行的总和：1/1+1/2+1/3+...+1/n。考虑到在 C++ 中的评估并不完全准确，求和的顺序起着重要作用。1/n+1/(n-1)+...+1/2+1/1 表达式给出了更准确的结果。所以我需要找出求和的顺序，这提供了最大的准确性。我什至不知道从哪里开始。首选的实现语言是 C++。对不起，我的英语，如果有任何错误。

简而言之：我如何执行a+b使得由于截断而导致的任何精度损失远离零而不是接近零？

长篇大论

我正在计算一长串浮点值的总和，以计算集合的样本均值和方差。由于Var(X) = E(X ² ) - E(X) ²，保持所有数字的运行计数、到目前为止所有数字的总和以及迄今为止所有数字的平方和就足够了。

到现在为止还挺好。

但是，绝对需要E(X ² ) > E(X) ²，由于浮点精度并非总是如此。在伪代码中，问题是这样的：

对于可变序列，这不是一个大问题——你最终会稍微低估方差，但这通常不是一个大问题。然而，对于具有非零均值的常数或几乎常数集，它可能意味着E(X ² ) < E(X) ²，导致计算出的方差为负，这违反了使用代码的预期。

现在，我知道了 Kahan Summation，这不是一个有吸引力的解决方案。首先，它使代码容易受到优化变幻莫测的影响（取决于优化标志，代码可能会或可能不会出现这个问题），其次，问题并不是真正由于精度 - 这已经足够了 - 这是因为加法引入了系统误差趋于零。如果我能执行这条线

为了确保 sqrVal 向上而不是向下舍入到 sumOfSquares 的精度，我会有一个数值上合理的解决方案。但我怎样才能做到这一点？

_{编辑：已完成的问题 - 为什么在标签字段的下拉列表中按 enter 无论如何都会提交问题？}

在我们的项目中，我们从用户那里获取两个浮点数，将它们存储在整数寄存器中，并将它们视为 IEEE 754 单精度浮点数，通过掩码来操作位。因此，在将分数值的 23 位相乘后，如果我想返回单精度浮点数（32 位）作为乘积，是否应该考虑放置在 LO 寄存器中的结果？

请参阅此代码：

当我在 Firefox 3.5 中看到我的控制台时， 的值jsonParsed是四舍五入的数字：

尝试了不同的值，结果相同（四舍五入）。

我也没有得到它的四舍五入规则。714341252076979136 舍入为 714341252076979200，而 714341252076979135 舍入为 714341252076979100。

为什么会这样？

运行与.NET 中的双乘法是否损坏有关的快速实验？并阅读了几篇关于 C# 字符串格式的文章，我认为：

将是此 C 代码的 C# 等效项：

但是 C# 产生输出：

尽管我在调试器中显示的值等于 6.89999999999999946709（而不是 6.9）。

与显示格式要求的精度的 C 相比：

这是怎么回事？

（Microsoft .NET Framework 版本 3.51 SP1 / Visual Studio C# 2008 速成版）

我有数值计算的背景和在各种平台上实施区间算术的经验 - 一种由于复杂数值系统的精度限制而估计误差的技术。要获得赏金，请不要尝试解释存储精度 - 在这种情况下，它是 64 位双精度 ULP 的差异。

为了获得赏金，我想知道 .Net 如何（或是否）可以将 double 格式化为 C 代码中可见的请求精度。

为什么7.30 - 7.20ruby​​ 中的这段代码返回0.0999999999999996，而不是0.10？

但如果我会写7.30 - 7.16，例如，一切都会好起来的，我会得到0.14的。

什么问题，我该如何解决？

为什么 NaN 值的比较与所有其他值的行为不同？也就是说，与运算符 ==、<=、>=、<、>（其中一个或两个值为 NaN）的所有比较都返回 false，这与所有其他值的行为相反。

我想这在某种程度上简化了数值计算，但我找不到明确说明的原因，甚至在Kahan的关于 IEEE 754 状态的讲义中也没有，它详细讨论了其他设计决策。

在进行简单的数据处理时，这种异常行为会造成麻烦。例如，在 C 程序中对某个实值字段的记录列表进行排序时，我需要编写额外的代码来处理 NaN 作为最大元素，否则排序算法可能会变得混乱。

编辑： 到目前为止的答案都认为比较 NaN 是没有意义的。

我同意，但这并不意味着正确答案是错误的，而是不是布尔值 (NaB)，幸运的是它不存在。

因此，在我看来，比较返回真或假的选择是任意的，对于一般数据处理，如果它遵守通常的规律（== 的自反性，<，==，> 的三分法），以免数据结构依靠这些法律变得混乱。

所以我要求打破这些法律的一些具体优势，而不仅仅是哲学推理。

编辑 2： 我想我现在明白为什么将 NaN 设为最大值是一个坏主意，它会弄乱上限的计算。

NaN != NaN 可能是可取的，以避免检测循环中的收敛，例如

但是，最好通过将绝对差异与小限制进行比较来编写。所以恕我直言，这是在 NaN 打破反身性的一个相对较弱的论据。

假设我有一个十六进制数“4072508200000000”，并且我希望将其代表的浮点数 (293.03173828125000) 以 IEEE-754 双精度格式放入 JavaScript 变量中。

我可以想到一种使用一些掩码和调用 pow() 的方法，但是有没有更简单的解决方案？

需要客户端解决方案。

这可能会有所帮助。这是一个网站，可让您输入 IEEE-754 的十六进制编码并分析尾数和指数。

http://babbage.cs.qc.edu/IEEE-754/64bit.html

因为人们总是倾向于问“为什么？”，原因如下：我正在尝试填写 Google 的 Procol Buffers (protobuf) 的现有但不完整的实现。