Loss of precision on BigDecimal operations starting from 1.7.20

[cburgmer]

Two examples:

$ irb
io/console not supported; tty will not be manipulated
irb(main):001:0> RUBY_DESCRIPTION
=> "jruby 1.7.19 (1.9.3p551) 2015-01-29 20786bd on Java HotSpot(TM) 64-Bit Server VM 1.8.0_51-b16 [Windows 7-amd64]"
irb(main):002:0> require 'bigdecimal'
=> true
irb(main):003:0> BigDecimal.new("1") / BigDecimal.new("3")
=> #<BigDecimal:6e6d5d29,'0.33333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333E0',200(204)>

vs

$ irb
io/console not supported; tty will not be manipulated
irb(main):001:0> RUBY_DESCRIPTION
=> "jruby 1.7.20 (1.9.3p551) 2015-05-04 3086e6a on Java HotSpot(TM) 64-Bit Server VM 1.8.0_51-b16 [Windows 7-amd64]"
irb(main):002:0> require 'bigdecimal'
=> true
irb(main):003:0> BigDecimal.new("1") / BigDecimal.new("3")
=> #<BigDecimal:13d9cbf5,'0.33333333E0',8(12)>

I would expect full precision, as previous versions of JRuby offered. The change in newer versions hasn't been flagged in the changelogs. I am assuming the change was introduced in #2537.

Considering this change is expected - unless the intention of it is made clear and an alternate solution exists, this is a blocker for us upgrading to newer JRuby versions, as it breaks existing behaviour.

[kares]

on 1.9.3 (which JRuby 1.7.x tries to stay compatible with) you do not get that much precision either :

1.9.3-p551 :004 > require 'bigdecimal'
 => true 
1.9.3-p551 :005 > BigDecimal.new("1") / BigDecimal.new("3")
 => #<BigDecimal:80c7d0,'0.3333333333 33333333E0',18(36)> 

... so you should probably not expect to fully revert to <= 1.7.20 behaviour

[headius]

This is unlikely to be fixed in 1.7.x. It appears to still be an issue in 9k, which has a longer tail.

[kares]

have put a 'fix' for this regression in for 9.2 (only), since I have made some other changes to BigDecimal.
... ATM matching up precision with MRI seems impossible without some more refactoring (time put in).
however there's some tests (such as mentioned in the report) that are expected to guard regressing ...