Skip to content

Instantly share code, notes, and snippets.

@clemens
Created November 23, 2011 15:14
Show Gist options
  • Save clemens/1388927 to your computer and use it in GitHub Desktop.
Save clemens/1388927 to your computer and use it in GitHub Desktop.
Ruby 1.9.3 BigDecimal bug?
>> 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?!
@bhuga
Copy link

bhuga commented Nov 23, 2011

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.

@clemens
Copy link
Author

clemens commented Nov 23, 2011

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