-
-
Notifications
You must be signed in to change notification settings - Fork 925
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Loss of precision on BigDecimal operations starting from 1.7.20 #3846
Comments
on 1.9.3 (which JRuby 1.7.x tries to stay compatible with) you do not get that much precision either :
... so you should probably not expect to fully revert to <= 1.7.20 behaviour |
This is unlikely to be fixed in 1.7.x. It appears to still be an issue in 9k, which has a longer tail. |
esp. on division/multiplication - some parts now match source closer however there's a fundamental issue in terms of MRI keeping the precision of a constructed number, while Java's BigDecimal does not ... so in the end we end up with different precision based on input. this needs to be cared out carefully as going 'too far' some of the ruby specs never finish computing (division atm) ... closes jruby#3846, jruby#4200 (we have tests guarding against regression)
esp. with division/multiplication - some parts now match C source closer however there's a fundamental difference in terms of MRI keeping the precision of a constructed number, while Java's BigDecimal doesn't ... thus we will tend to end up with different precisions based on input. this needs to be cared out carefully as going 'too far', as some of the ruby specs never finish computing (division atm) ... closes jruby#3846, jruby#4200 (we have tests guarding against regression)
have put a 'fix' for this regression in for 9.2 (only), since I have made some other changes to BigDecimal. |
Two examples:
vs
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.
The text was updated successfully, but these errors were encountered: