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

BigDecimal regression - to_d inconsistent with other numeric classes #51

Closed
jhawthorn opened this Issue Dec 22, 2016 · 9 comments

Comments

Projects
None yet
4 participants
@jhawthorn

jhawthorn commented Dec 22, 2016

I originally filed this on bugs.ruby-lang.org, not sure if this is a more appropriate place.

As of ruby 2.4.0-rc1, BigDecimal() was changed to raise exceptions on invalid input, which is more consistent with the other numeric types. Unfortunately, String#to_d now also raises errors, which is inconsistent with the other to_* methods (to_i, to_f), which return 0 on error.

Under ruby 2.4.0-rc1:

> require 'bigdecimal'
> require 'bigdecimal/util'
> "invalid".to_d
ArgumentError: invalid value for BigDecimal(): "invalid"
> "invalid".to_i
=> 0
> "invalid".to_f
=> 0.0

Under ruby 2.3.3 or 2.4.0preview3:

> "invalid".to_d
=> #<BigDecimal:55871ca1f808,'0.0',9(9)>
> "invalid".to_i
=> 0
> "invalid".to_f
=> 0.0

There's also a further problem that BigDecimal() still doesn't behave the same as Integer() when given a string with the number at the start:

Under ruby 2.4.0-rc1:

> BigDecimal("2 turtle doves")
=> 0.2e1
> Integer("2 turtle doves")
ArgumentError: invalid value for Integer(): "2 turtle doves"
> Float("2 turtle doves")
ArgumentError: invalid value for Float(): "2 turtle doves"

So BigDecimal is still inconsistent.

@mrkn

This comment has been minimized.

Collaborator

mrkn commented Jan 16, 2017

The patch posted by Piotr Szmielew in Redmine is good to fix this.
I'll apply this patch later.
Thanks for reporting the bug.

By the way,

I originally filed this on bugs.ruby-lang.org, not sure if this is a more appropriate place.

Both places are appropriate.
But I prefer to use GitHub issue because it is more useful than Redline.

@esse

This comment has been minimized.

Contributor

esse commented Jan 16, 2017

@mrkn Should I make pull request with that? Or is patch file provided through redmine enough?

@mrkn

This comment has been minimized.

Collaborator

mrkn commented Jan 16, 2017

@esse Would you please submit your pull request?
I want to import your contribution as your commit.

@esse

This comment has been minimized.

Contributor

esse commented Jan 18, 2017

@mrkn pull request added: #55

@mrkn

This comment has been minimized.

Collaborator

mrkn commented Jan 18, 2017

@esse Thank you. I'll check it at this weekend.

@abezzub

This comment has been minimized.

abezzub commented Mar 23, 2017

I still see this in ruby 2.4.1. Did it not make the cut?

@mrkn

This comment has been minimized.

Collaborator

mrkn commented Mar 27, 2017

@abezzub Could you please try gem update bigdecimal?

@abezzub

This comment has been minimized.

abezzub commented Mar 27, 2017

I did, thanks. I see that issue is fixed in version 1.3.2. If I understand correctly, bigdecimal is shipped with Ruby, so it would be nice if a version with the fix were included in latest Ruby release.

@mrkn

This comment has been minimized.

Collaborator

mrkn commented Mar 27, 2017

@abezzub I believe the latest bigdecimal will be included in the next update of Ruby.
BTW, now bigdecimal is a default gem, so the version of bigdecimal is maintained independently.
You can update default gems independently of Ruby version.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment