What does Rails do with basic Ruby's math behaviour?

Hi,

This is my first post on this mailing list and I would like to thanks
the
authors and the community for this great tools.

After a couple of weeks happily playing with Rails, I got bitten by a
strange behaviour drift between Rails and Ruby:

Plain Ruby:

$ irb
irb(main):001:0> 2 / 5
=> 2/5
irb(main):003:0> 2.to_f / 5.to_f
=> 0.4

Ruby On Rails:

$ cd /tmp
$ rails new t1
$ cd t1
$ rails console
Loading development environment (Rails 3.2.9)
irb(main):001:0> 2 / 5
=> 0
irb(main):002:0> 2.to_f / 5.to_f
=> 0.4

So I just don’t get why 2/5 doesn’t return the same result in both
cases.
Personally, I found this behaviour dangerous since many third party
libraries will be based on it. I had a quick look at
Active Support Core Extensions — Ruby on Rails Guides but
could
not find any mention of it.

Can someone explain me why and how Rails does that?

Best regards,


Nicolas D.

I forgot to say that I am using ruby 1.9.3-p327.

On Thu, Dec 6, 2012 at 9:41 AM, Nicolas D.
[email protected]wrote:

$ irb
$ rails console
could not find any mention of it.

Can someone explain me why and how Rails does that?

Best regards,


Nicolas D.


Nicolas D.

On Thursday, December 6, 2012 8:41:20 AM UTC, Nicolas D. wrote:

$ irb
irb(main):001:0> 2 / 5
=> 2/5
irb(main):003:0> 2.to_f / 5.to_f
=> 0.4

That’s not how it behaves for me. I get 2 / 5 == 0 in both cases. The
ruby
mathn library (part of the stdlib) does do this (and I really wish it
wouldn’t). Perhaps something in your irbrc pulls this in ?

Fred

On Fri, Dec 7, 2012 at 12:46 PM, Frederick C. <
[email protected]> wrote:

strange behaviour drift between Rails and Ruby:
That’s not how it behaves for me. I get 2 / 5 == 0 in both cases. The ruby
mathn library (part of the stdlib) does do this (and I really wish it
wouldn’t). Perhaps something in your irbrc pulls this in ?

Not .irbrc. I forgot I had an alias on irb which pull -m option… :frowning:
So
the error was from my environment. Thanks for your reply.

Sorry for the noise.


Nicolas D.