blocks|key|3038236|text|在使用浮点运算时，有两个常见的陷阱。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3038237|的第一个问题是浮点数具有固定的精度。在实践中，这要么是1)对你来说没有问题，要么是2)灾难性的，或者3)介于两者之间。请考虑以下几点：|offset|length|style|BOLD|3038238|#+float
1.0e%2B25+-+9999999999999999900000000.0
#=>+0.0

#+bigdecimal
BigDecimal("1.0e%2B25")+-+BigDecimal("9999999999999999900000000.0")
#=>+100000000|code-block|syntax|javascript|3038239|精度差一亿！很严肃，对吧？|3038240|但精度误差仅为原始值的0.000000000000001%25左右。这真的是由你来决定这是不是一个问题。但是这个问题可以通过使用BigDecimal来解决，因为它具有任意精度。您唯一的限制是Ruby可以使用的内存。|CODE|3038241|的第二个问题是，浮点数不能准确地表示所有分数。特别是，它们在小数方面有问题，因为Ruby+(和大多数其他语言)中的浮点是二进制浮点。例如，十进制分数0.2是一个永远重复的二进制分数(0.001100110011...)。无论精度是多少，这永远不能以二进制浮点数的形式准确存储。|3038242|当你对数字进行四舍五入时，这会产生很大的差异。考虑一下：|3038243|#+float
(0.29+*+50).round
#=>+14++#+not+correct

#+bigdecimal
(BigDecimal("0.29")+*+50).round
#=>+15++#+correct|3038244|BigDecimal可以精确地描述小数。然而，也有一些分数不能用小数精确地描述。例如，1/9是一个永远重复的小数(0.1111111111111...)。|3038245|同样，当你舍入一个数字时，这会咬你一口。考虑一下：|3038246|#+bigdecimal
(BigDecimal("1")+/+9+*+9+/+2).round
#=>+0++#+not+correct|3038247|在这种情况下，使用十进制浮点仍然会产生舍入误差()。|3038248|一些结论：|3038249|如果您使用小数进行计算，|3038250|小数浮点数将非常棒(对于example).|unordered-list-item|3038251|Ruby's+BigDecimal，如果您需要任意精度浮点数，并且并不真正关心它们是十进制浮点还是二进制浮点数，则它也很有效。|3038252|如果您处理(科学)数据，您通常需要处理固定精度的数字；Ruby的内置浮点数可能就足够了。|3038253|您永远不能期望任何类型的浮点数的算术在所有情况下都是精确的。|3038254|3038255|entityMap^0|0|7|1O|0|0|0|D|0|0|2X|1Q|A|0|0|3U|22|3|2J|H|0|0|S|0|0|0|25|0|A|17|3|1L|I|0|0|P|0|0|0|Q|0|0|5|0|0|C|0|0|L|0|0|1R|7|A|0|0|18|0|0|U|0|0^^$0|@$1|2|3|4|5|6|7|1L|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|1M|8|@$D|1N|E|1O|F|G]]|9|@]|A|$]]|$1|H|3|I|5|J|7|1P|8|@]|9|@]|A|$K|L]]|$1|M|3|N|5|6|7|1Q|8|@$D|1R|E|1S|F|G]]|9|@]|A|$]]|$1|O|3|P|5|6|7|1T|8|@$D|1U|E|1V|F|G]|$D|1W|E|1X|F|Q]]|9|@]|A|$]]|$1|R|3|S|5|6|7|1Y|8|@$D|1Z|E|20|F|G]|$D|21|E|22|F|Q]|$D|23|E|24|F|Q]]|9|@]|A|$]]|$1|T|3|U|5|6|7|25|8|@$D|26|E|27|F|G]]|9|@]|A|$]]|$1|V|3|W|5|J|7|28|8|@]|9|@]|A|$K|L]]|$1|X|3|Y|5|6|7|29|8|@$D|2A|E|2B|F|G]|$D|2C|E|2D|F|Q]|$D|2E|E|2F|F|Q]|$D|2G|E|2H|F|Q]]|9|@]|A|$]]|$1|Z|3|10|5|6|7|2I|8|@$D|2J|E|2K|F|G]]|9|@]|A|$]]|$1|11|3|12|5|J|7|2L|8|@]|9|@]|A|$K|L]]|$1|13|3|14|5|6|7|2M|8|@$D|2N|E|2O|F|G]]|9|@]|A|$]]|$1|15|3|16|5|6|7|2P|8|@$D|2Q|E|2R|F|G]]|9|@]|A|$]]|$1|17|3|18|5|6|7|2S|8|@$D|2T|E|2U|F|G]]|9|@]|A|$]]|$1|19|3|1A|5|1B|7|2V|8|@$D|2W|E|2X|F|G]]|9|@]|A|$]]|$1|1C|3|1D|5|1B|7|2Y|8|@$D|2Z|E|30|F|G]|$D|31|E|32|F|Q]]|9|@]|A|$]]|$1|1E|3|1F|5|1B|7|33|8|@$D|34|E|35|F|G]]|9|@]|A|$]]|$1|1G|3|1H|5|1B|7|36|8|@$D|37|E|38|F|G]]|9|@]|A|$]]|$1|1I|3|-4|5|6|7|39|8|@]|9|@]|A|$]]|$1|1J|3|-4|5|6|7|3A|8|@]|9|@]|A|$]]]|1K|$]]

There are two common pitfalls when working with floating point arithmetic.

The first problem is that Ruby floating points have fixed precision. In practice this will either be 1) no problem for you or 2) disastrous, or 3) something in between. Consider the following:

<pre><code># float
1.0e+25 - 9999999999999999900000000.0
#=&gt; 0.0

# bigdecimal
BigDecimal("1.0e+25") - BigDecimal("9999999999999999900000000.0")
#=&gt; 100000000
</code></pre>

A precision difference of 100 million! Pretty serious, right?

Except the precision error is only about 0.000000000000001% of the original number. It really is up to you to decide if this is a problem or not. But the problem is removed by using <code>BigDecimal</code> because it has arbitrary precision. Your only limit is memory available to Ruby.

The second problem is that floating points cannot express all fractions accurately. In particular, they have problems with decimal fractions, because floats in Ruby (and most other languages) are binary floating points. For example, the decimal fraction <code>0.2</code> is an eternally-repeating binary fraction (<code>0.001100110011...</code>). This can never be stored accurately in a binary floating point, no matter what the precision is.

This can make a big difference when you're rounding numbers. Consider:

<pre><code># float
(0.29 * 50).round
#=&gt; 14 # not correct

# bigdecimal
(BigDecimal("0.29") * 50).round
#=&gt; 15 # correct
</code></pre>

A <code>BigDecimal</code> can describe decimal fractions precisely. However, there are fractions that cannot be described precisely with a decimal fraction either. For example <code>1/9</code> is an eternally-repeating decimal fraction (<code>0.1111111111111...</code>). 

Again, this will bite you when you round a number. Consider:

<pre><code># bigdecimal
(BigDecimal("1") / 9 * 9 / 2).round
#=&gt; 0 # not correct
</code></pre>

In this case, using decimal floating points will still give a rounding error.

Some conclusions:

<ul>
<li>Decimal floats are awesome if you do calculations with decimal fractions (money, for example).</li>
<li>Ruby's <code>BigDecimal</code> also works well if you need arbitrary precision floating points, and don't really care if they are decimal or binary floating points.</li>
<li>If you work with (scientific) data, you're typically dealing with fixed precision numbers; Ruby's built-in floats will probably suffice.</li>
<li>You can never expect arithmetic with any kind of floating point to be precise in all situations.</li>
</ul>

Is my understanding correct that with Ruby <code>BigDecimal</code> types (even with varying precision and scale lengths) should calculate accurately or should I anticipate floating point shenanigans?

All my values within a Rails application are <code>BigDecimal</code> type and I'm seeing some errors (they do have different decimal lengths), hoping it's just my methods and not my object types.

Ruby BigDecimal sanity check (floating point newb)

我对Ruby BigDecimal类型(即使具有不同的精度和小数位数长度)应该准确计算的理解是正确的，还是应该预期到浮点恶作剧？我在Rails应用程序中的所有值都是BigDecimal类型，并且我看到了一些错误(它们的小数长度不同)，希望这只是我的方法而不是我的对象类型。

问Ruby BigDecimal健全性检查(浮点newb)
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问Ruby BigDecimal健全性检查(浮点newb)EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问Ruby BigDecimal健全性检查(浮点newb)
EN