From: David MacMahon <davidm@...>
Date: 2013-09-10T16:33:27-07:00
Subject: [ruby-core:57121] Re: [ruby-trunk - Bug #8883][Rejected] Rational	canonicalization unexpectedly converts to Fixnum

OK. I agree that requiring mathn avoids that buggy part.  Thanks for clarifying.  I guess I'm just a little uncomfortable with Rationals and Fixnums being promoted/demoted as needed, but maybe it's all OK and I'm just being paranoid.

While playing around with this, I see that integer Floats also have some special handling:

# Without mathn...

$ ruby -e 'p [1/2.0, 1/2.5]'
[0.5, 0.4]

# With mathn...

$ ruby -r mathn -e 'p [1/2.0, 1/2.5]'
[(1/2), 0.4]

Oddly though, this can result in non-reduced Rationals:

$ ruby -r mathn -e 'p [2/2.0, 2/2.5]'
[(2/2), 0.8]

Weird.

Also, why do integer Floats not get changed to Fixnums like Rational and Complex do?

$ ruby -r mathn -e 'p Rational(1).class'
Fixnum

$ ruby -r mathn -e 'p Complex(1).class'
Fixnum

$ ruby -r mathn -e 'p Float(1).class'
Float

Thanks,
Dave

On Sep 10, 2013, at 3:28 PM, marcandre (Marc-Andre Lafortune) wrote:

> 
> Issue #8883 has been updated by marcandre (Marc-Andre Lafortune).
> 
> Status changed from Open to Rejected
> 
> Mmm, sorry, misread.
> 
> I think the idea is that the buggy part (Rational(2) / Rational(3)  # => 0) won't happen if you require 'mathn'
> 
> ----------------------------------------
> Bug #8883: Rational canonicalization unexpectedly converts to Fixnum
> https://bugs.ruby-lang.org/issues/8883#change-41727
> 
> Author: melquiades (Paul Cantrell)
> Status: Rejected
> Priority: Normal
> Assignee: 
> Category: lib
> Target version: 
> ruby -v: ruby 2.0.0p247 (2013-06-27 revision 41674) [x86_64-darwin12.3.0]
> Backport: 1.9.3: UNKNOWN, 2.0.0: UNKNOWN
> 
> 
> The documentation for Rational (http://www.ruby-doc.org/core-2.0.0/Rational.html) states that the result of creating or doing arithmetic on Rationals returns Rationals, as one would expect. Examples from the docs:
> 
>    Rational(1)      #=> (1/1)
>    3.to_r           #=> (3/1)
>    Rational(-2, 9) * Rational(-9, 2)  #=> (1/1)
> 
> These all work as documented in 1.9. In 2.0, however, they all return Fixnum:
> 
>    Rational(1)      #=> 1
>    3.to_r           #=> 3
>    Rational(-2, 9) * Rational(-9, 2)  #=> 1
> 
> This leads to unexpected behavior:
> 
>    Rational(2) / Rational(3)  # => 0  ...but returns (2/3) in 1.9
> 
> That behavior is potentially dangerous. Math that may *usually* work, but suddenly start suffering from truncation errors depending on intermediate results. For example:
> 
>  def should_always_return_one(a, b, c)
>    (Rational(a, c) + Rational(b, c)) / (a + b) * c
>  end
> 
> Under 1.9:
> 
>    should_always_return_one(2, 3, 7) #=> (1/1)
>    should_always_return_one(2, 4, 7) #=> (1/1)
>    should_always_return_one(2, 5, 7) #=> (1/1)
>    should_always_return_one(2, 6, 7) #=> (1/1)
> 
> Under 2.0:
> 
>    should_always_return_one(2, 3, 7) #=> 1
>    should_always_return_one(2, 4, 7) #=> 1
>    should_always_return_one(2, 5, 7) #=> 0   Oops!
>    should_always_return_one(2, 6, 7) #=> 1
> 
> Either the docs are wrong, or this is a bug. I vote bug. Whether arithmetic expressions truncate the result should not depend on whether intermediate values just happen to be integers! Such behavior renders Rational almost too dangerous to use in situations where exact results are required. (Yes, I realize that requiring 'mathn' fixes this, but even with such a workaround as an option, this is dangerously broken. See also #2121.) Note that floating point arithmetic does _not_ exhibit this behavior.
> 
> 
> 
> -- 
> http://bugs.ruby-lang.org/