为什么浮点模量精度很重要？

当前，大多数Smalltalk方言都实现了幼稚的不精确浮动模数（fmod / remainder）。
我刚刚进行了更改，以提高Squeak / Pharo并最终提高了其他Smalltalk对标准（IEEE 754，ISO / IEC 10967）的遵守程度，就像我对其他最新浮点运算所做的那样。

但是，对于采用这些更改，我希望遵守标准不足以说服我的同龄人，因此解释一下在什么情况下这种准确性确实很重要将对我有很大帮助。到目前为止，我自己找不到一个很好的例子。

这里有谁知道为什么/何时/何地（IOW在哪种算法中）如此精确的模数很重要吗？

arithmetic floating-point

— 又名
source

我认为您可能会在计算科学上得到更好的答案，因为此类问题在其（子）领域中更为重要。无论如何，问题都在这里，您应该在重新发布前几天给我们的答复者。

— 拉斐尔

我已经看到代码依赖于fmod / modf的准确性，这使我感到震惊，但是某种语言敢于实现幼稚的不精确浮点模数的可能性似乎更加可怕。示例代码：（1）取余数。（2）如果为零，则停止。（3）将其乘以2，然后转到（1）。一个人可以在此过程中做一些有用的工作，但关键是该过程的终止取决于余数的准确度和乘以2的准确度。不确定在此是否应该给出更完整的答案，因为计算科学似乎更合适对于这个问题。

— Thomas Klimpel

一个猜想：归一化三角函数的输入。

— 保罗·克莱顿

@ThomasKlimpel如果您找到参考文献，我很感兴趣。注意，朴素的余数定义为（x-（（y / x）截断* x）），并且IEEE舍入到最接近的偶数运算，我们可以证明确切Rem（x，y）== 0 => naiveRem（x，y） == 0。问题是相反的-错误的精确除法为正-像naiveRem（4.0,0.1）== 0.0不幸的是，在许多情况下，它适合幼稚的期望！

— aka.nice 2014年

@ PaulA.Clayton是的，也许是正弦度数……虽然，我的猜测是，朴素的rem和精确的rem一样好，直到大约。1e16度是因为360仅设置了6位的范围，并且因为360的除数似乎永远不会舍入360的倍数的前身...对于弧度，一个体面的库需要多精度，所以精确的rem限于双精度在这种情况下真的有帮助吗？

— aka.nice，2014年

请注意，不精确的浮点实现会影响天气。

已经有测试在不同的硬件上以相同的输入来运行天气预报，并且这些预测有所不同。如果您运行的是迭代算法，则此处或此处的舍入差异较小可能会导致蝴蝶效应，将阳光变为雨水。

已经仔细考虑了标准（IEEE 754，ISO / IEC 10967）中的舍入规则，因此数值算法的行为具有最准确的可预测性，并且每次都能产生相同的结果。如果不遵循为这些取整规则设计的标准数值算法，则会破坏该结果，并且迭代算法（如天气预报）甚至可以给出随机结果。

（这还不是说天气预报吗？

— 戈斯温·冯·布雷德洛
source

另一方面，如果蝴蝶效应将阳光变成雨，那么您的结果无论如何都没有用。

— gnasher729

曾几何时，我将浮点数据保存为ASCII码且位数不足。一个客户想给我看一个问题，但是从ASCII文件恢复数据后，问题消失了。我说过几下功夫没关系，如果他的病得病了，我无能为力。他说这是他的生意，我的职责是提供能够重现他自己问题的软件。他是对的。

— aka.nice

这就是为什么您应该使用％a将保存的浮点数输出为十六进制的原因。

— Goswin von Brederlow