Peña wrote:
BigDecimal.new(self.to_s)
=> true
z==y
=> true
x==z
=> true
z==x
=> true
–snip–
However (among other problems):
x = (1.0/3.0).to_dec
y = 1.0.to_dec / 3.0.to_dec
x == y # => false
HTH,
Michael
Peña wrote:
BigDecimal.new(self.to_s)
=> true
z==y
=> true
x==z
=> true
z==x
=> true
–snip–
However (among other problems):
x = (1.0/3.0).to_dec
y = 1.0.to_dec / 3.0.to_dec
x == y # => false
HTH,
Michael
From: Michael U. [mailto:[email protected]]
hmm, i thought this was already answered by others… gotta check…
irb(main):023:0* x=1.0.to_dec/3.0.to_dec
=> #<BigDecimal:b7e45e14,‘0.3333333333 333333E0’,16(24)>
irb(main):024:0> x+x+x == 1.0.to_dec
=> true
kind regards -botp
Peña wrote:
=> true
Strange, I tested this on two different machines and both gave false
to your last expression. Did you modify BigDecimal#== ?
Regards,
Michael
This is why I prefer to use fixed decimal. In your own private code,
it’s easy enough to implement. You just decide how many “decimals” your
int’s should have.
Getting correct programs using floats are really hard. Heck, MS Excell
don’t even get Sum and Mean right. (Microsoft, usually, use naïve
algorithm’s that don’t take care of underflow and rounding errors).
From: Michael U. [mailto:[email protected]]
yes. i just used one of the codes posted here… not sure if it was even
your suggested code though. nonetheless, what were you expecting? that
1/3 can be represented exactly in decimal?
but i really want a way to override float literals, so i do not litter
all those to_decs :)) Of course, floats has a lot of merits, but it
gives too many surprises fr just a few dec samples. businesswise, it has
little use.
kind regards -botp
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
Sponsor our Newsletter | Privacy Policy | Terms of Service | Remote Ruby Jobs