Bug #17214: BigDecimal exponentiation gives incorrect results

• Status: Rejected
• Assignee: -
• Target version: -
• ruby -v: ruby 2.7.1p83 (2020-03-31 revision a0c7c23c9c) [x86_64-linux]
• Backport: 2.5: UNKNOWN, 2.6: UNKNOWN, 2.7: UNKNOWN

[karatedog (Földes László)]

This is an incorrect value:

(BigDecimal("2222") ** BigDecimal("3.5")).to_i
# => 517135311000

This is the correct value (within Float precision):

2222 ** 3.5
# => 517135308457.25256

As the Base gets larger, the problem is more visible. Wrong value, number of trailing zeroes increase:

(BigDecimal("22222") ** BigDecimal("3.5")).to_i
# => 1635840670000000

Nearing maximum Float precision:

22222 ** 3.5
# => 1635840670214066.5

[sawa (Tsuyoshi Sawada)]

• Description updated (diff)

[nobu (Nobuyoshi Nakada)]

• Status changed from Open to Rejected

BigDecimal instances hold the precision, and it is not enough in that case.
You need to override the default precision in some operations.

BigDecimal(2222).power(3.5, Float::DIG).to_i #=> 517135308457

[karatedog (Földes László)]

If I increase the precision of the two arguments ("2222", "3.5"), but leave the operation's precision on default, the result still will be wrong.

(BigDecimal("2222",10000) ** BigDecimal("3.5",10000)).to_i
# => 517135311000

This is incorrect with #power as well:

(BigDecimal("2222",10000).power(BigDecimal("3.5",10000))).to_i
# => 517135311000

So the good result relies only on the precision of the operation which is not straightforward immediately for the developer (because the statement will return a value).

To sum up:

1. Only #power can be used for proper exponentiation, as #** cannot be given any argument and thus will give almost always wrong results if used with large numbers. Existing code might need to be rewritten, changing class from Float to BigDecimal will not be idempotent.
2. BigDecimal is advertised as an "arbitrary precision library" yet using the defaults is less precise than Float. This is misleading, it will bite newcomers in the back.

I think this should be documented and/or fine-tuned, the above two violates the Principle of Least Surprise.