Skip to content
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

High precision BigDecimal to Rational conversion wildly inaccurate #4711

Closed
joshwlewis opened this issue Jul 10, 2017 · 1 comment
Closed
Assignees
Labels
Milestone

Comments

@joshwlewis
Copy link

Environment

  • Darwin 16.6.0 (MacOS Sierra 10.12.5)
  • jruby 9.1.8.0 (2.3.1) 2017-03-06 90fc7ab Java HotSpot(TM) 64-Bit Server VM 25.131-b11 on 1.8.0_131-b11 +jit [darwin-x86_64]

Expected Behavior

In each MRI version I've tried, I am able to convert a high-precision BigDecimal to a reasonably similar Rational value. For instance, in MRI 2.4.1:

require 'bigdecimal'
# => true

BigDecimal.new("3.141592653589793238462643383279502884197169").to_r
# => (3141592653589793238462643383279502884197169/1000000000000000000000000000000000000000000)

_.to_f
# => 3.141592653589793

Actual Behavior

require 'bigdecimal'
# => true

BigDecimal.new("3.141592653589793238462643383279502884197169").to_r
# => (448798950512827605494663340468500412028167/1317624576693539401)

_.to_f
# => 3.4061215800865547e+23

I'd expect something in the region of 3.14 here, but instead, the result is approximately 340 sextillion.

Other info

@kares kares added this to the JRuby 9.2.0.0 milestone Jul 10, 2017
@kares kares added the core label Jul 10, 2017
@kares kares self-assigned this Jul 11, 2017
kares added a commit to kares/jruby that referenced this issue Jul 11, 2017
kares added a commit to kares/jruby that referenced this issue Jul 11, 2017
@headius
Copy link
Member

headius commented Jul 11, 2017

Yeah, this is pretty wacky. Looks like @kares is looking into it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants