Project

General

Profile

Actions

Bug #17214

closed

BigDecimal exponentiation gives incorrect results

Added by karatedog (Földes László) over 3 years ago. Updated over 3 years ago.

Status:
Rejected
Assignee:
-
Target version:
-
ruby -v:
ruby 2.7.1p83 (2020-03-31 revision a0c7c23c9c) [x86_64-linux]
[ruby-core:100297]

Description

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
Actions #1

Updated by sawa (Tsuyoshi Sawada) over 3 years ago

  • Description updated (diff)

Updated by nobu (Nobuyoshi Nakada) over 3 years ago

  • 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

Updated by karatedog (Földes László) over 3 years ago

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.

Actions

Also available in: Atom PDF

Like0
Like0Like0Like0