Bug #5309
closed
Added by brixen (Brian Shirai) about 13 years ago.
Updated about 13 years ago.
Description
0.6.to_r != "0.6".to_r
Is this a bug?
$ ruby -v
ruby 1.9.2p290 (2011-07-09 revision 32553) [x86_64-darwin10.8.0]
$ irb
ruby-1.9.2-p290 :001 > 0.6.to_r
=> (5404319552844595/9007199254740992)
ruby-1.9.2-p290 :002 > "0.6".to_r
=> (3/5)
ruby-1.9.2-p290 :003 > a = "%.55f" % 0.6
=> "0.5999999999999999777955395074968691915273666381835937500"
ruby-1.9.2-p290 :004 > b = "%.55f" % "0.6".to_f
=> "0.5999999999999999777955395074968691915273666381835937500"
ruby-1.9.2-p290 :005 > a == b
=> true
Thanks,
Brian
- Status changed from Open to Rejected
0.6.to_r is considered as a rational converted from a floating point number 0.5999999999999999777955395074968691915273666381835937500.
"0.6".to_r is considered as Rational(6, 10).
So they are slightly different number.
Use Float#rationalize
instead of to_r
, and you will get the same result as String#to_r
. I've argued before that Float#to_r
should be Float#rationalize
, though.
On Sep 12, 2011, at 2:06 PM, Brian Ford wrote:
0.6.to_r != "0.6".to_r
Is this a bug?
Probably not because
0.6.to_r
requires two conversions:
decimal floating point to binary floating point to rational
while
"0.6".to_r
only requires one conversion from decimal floating point to rational.
In the first case, the intermediate value is not exactly 3/5 so the
two sequences don't give you the same result.
Gary Wright
- ruby -v changed from ruby 1.9.2p290 (2011-07-09 revision 32553) [x86_64-darwin10.8.0] to -
Also available in: Atom
PDF
Like0
Like0Like0Like0Like0