Created
November 23, 2011 15:14
-
-
Save clemens/1388927 to your computer and use it in GitHub Desktop.
Ruby 1.9.3 BigDecimal bug?
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| >> require 'bigdecimal' | |
| => true | |
| >> require 'bigdecimal/util' | |
| => true | |
| >> BigDecimal('40.30') == 40.3 | |
| => true | |
| >> BigDecimal('40.90') == 40.9 | |
| => true | |
| >> BigDecimal('40.10') == 40.1 | |
| => true | |
| >> BigDecimal('49.10') == 49.1 | |
| => true | |
| >> BigDecimal('69.10') == 69.1 | |
| => false | |
| # WTF?! |
Oh, I see. :(
On the positive side: They've finally added to_d to BigDecimal itself (!) and Integer. I used to have to monkeypatch these ... :)
Anyway, thanks for the hints – I'll fix that some other way, then, I guess.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I see, sorry, I misunderstood the context of the question. The new bigdecimal constructors were added in 1.9.3 (allowing options other than string), so it may well have new coercion semantics for how it interacts with other numerics. And lo and behold, the 1.9.3 changelogs say that coercion semantics for bigdecimal been slightly mucked with, it's halfway down at http://svn.ruby-lang.org/repos/ruby/tags/v1_9_3_0/NEWS.
This particular case is not covered by those changelogs, and it may well be a bug in the intended semantics. But it looks like the implicit precision semantics are being deprecated, and probably this change is a result of the bigdecimal library now examining what it's being compared to and using a 'more correct' precision instead of some random default, which was probably below 16 in the past.
In any case, nasty upgrade gotcha, and making it work for both 1.9.3. and 1.9.2 may be hard, because the 1.9.3. constructors don't exist yet in 1.9.2. Ouch.