RoundingMode 的最准确枚举常量（用 Java 计算 Pi）答案

【问题标题】：Most accurate Enum Constant for RoundingMode (Calculating Pi in Java)RoundingMode 的最准确枚举常量（用 Java 计算 Pi）
【发布时间】：2013-08-08 20:29:41
【问题描述】：

我编写了一个计算 Pi 的程序。它使用double 类型，因此在这种情况下它自然只会将 Pi 计算到最多 16 位小数。

我正在尝试让我的代码采用BigDecimals 类型，以便我可以将 Pi 计算为更精确的数字（即更多小数位）。

我的进度可以看到>> here <<

我正在使用Madhava–Leibniz series 来计算 Pi：

     Pi = 4/1 + (-4/3) + 4/5 + (-4/7) + 4/9 + ... + 4/n

在我的程序中，我做了这样的划分：

     currentTerm=(double)-4/oddTerm;

在我更新的代码中，我已将其更改为：

    currentTerm = neg.divide(oddTerm, 10, RoundingMode.HALF_UP);

我希望这能给你一个想法或正在发生的事情。

我的问题是，在此示例中，RoundingMode 的哪个 Enum Constant 将是最好使用的（或更准确的？）... 显然，如果我使用不同的输出，Pi 的输出会发生显着变化。以下是完整列表：

另外，我是否正确使用10 的scale 进行此计算以获得最精确？

谢谢。

编辑将Scale 更改为 100；给 Pi 100dp。等等

【问题讨论】：

我不知道你为什么使用scale=10，使用 BigDecimal 的比例是任意的，你也可以使用 20 或 100 并获得更高的精度（当然，它会更慢） .关于四舍五入，我会选择 HALF_EVEN，它没有系统偏差。无论如何，由于您正在总结替代符号的术语，我猜 HALF_DOWN 或 HALF_UP 应该执行几乎相同。
感谢您的评论。此后，我将 Scale 更改为 100（因为直到几分钟前我才确定自己做了什么）。 Scalee 100 给了我 100dp 的 Pi。我想我会坚持使用 HALF_UP，尽管我在质疑我的数学，因为我的程序给出了3.14149265359...，并且我在 google Pi 上发现计算为 100dp 为3.14159265358... 我假设这与舍入有关.. .?
您知道莱布尼茨级数收敛非常缓慢，是吗？ en.wikipedia.org/wiki/Leibniz_formula_for_%CF%80
是的，我知道它的收敛速度不如其他方法/系列，但我认为它是最容易开始的。如果我能达到对程序感到满意的程度，我将探索其他算法:) 我的程序使用 5000 个术语为 Pi 提供以下 1000dp：3.1413926535917932383626433954795001141981798188345532196965187625458916006334194979629989247706731687102838238398361791574536367663058247375248339681750209539995182762289282761350508360315226843520701417644166609500807057357095090492110090220309058886968823519731751091437... 对我来说看起来不正确......
哦...我刚刚阅读了维基页面的Inefficiency 部分。这解释了为什么它是3.14139... 而不是3.14159... 感谢您强调这一点。我想我的数学是正确的毕竟（将收敛速度放在一边）

标签： java enums constants

【解决方案1】：

首先，请仔细阅读 Javadoc。它包含大量示例，说明每个 RoundingMode 的工作原理。

在真正的数学中，我们通常是 HALF_UP，因为这是老师在学校教我们的方式。 5.5 舍入为 6。5.4 舍入为 5。

【讨论】：

感谢您的评论。是的，我已经阅读了 Java 文档，但有点困惑。我认为 HALF_UP 是更好的选择。你说的很棒。谢谢:)

【解决方案2】：

没有。如果您将 PI 计算到大量小数位，则根本不应该四舍五入或缩放。你的问题真的没有意义。

【讨论】：

在计算能力（和知识）有限的情况下，您必须四舍五入才能得出一个可行（并且有些准确）的表示。如果 Pi 是一个无理数，那么 Pi 如何以给定的小数位数表示？你的回答没有道理。