Issue #13134 has been updated by Eli Sadoff.


I propose leaving the behavior the way it is. A float denominator is filled with possible unexpected behavior. For example, one would hypothesize that `(a/b).to_r == Rational("#{a}/#{b}")` yet `(3.1/2.0).to_r != Rational('3.1/2.0')`. The imprecision that can come with float denominators is why this behavior should not be allowed. Either we would have to allow for `(a/b).to_r == Rational("#{a}/#{b}")` to not always be true, or we would turn `Rational('3.1/2.0')` into `(6980579422424269/4503599627370496)` which defeats the purpose of the rational class. 

----------------------------------------
Bug #13134: Rational() inconsistency
https://bugs.ruby-lang.org/issues/13134#change-62515

* Author: Nobuyoshi Nakada
* Status: Assigned
* Priority: Normal
* Assignee: Kenta Murata
* Target version: 
* ruby -v: 
* Backport: 2.2: UNKNOWN, 2.3: UNKNOWN, 2.4: UNKNOWN
----------------------------------------
`Rational()` parses a float, an integer divided by an integer, and a float divided by an integer.

```ruby
Rational("3.1")     #=> (31/10)
Rational("3/2")     #=> (3/2)
Rational("3.1/2")   #=> (31/20)
```
But a float is not allowed as a denominator.

```ruby
Rational("3.1/2.0") #=> ArgumentError
```

I'd expect the last also passes and results in `(31/20)`, or the third also raises an `ArgumentError`

A patch to let all pass.
https://github.com/ruby/ruby/compare/trunk...nobu:parse_rat



-- 
https://bugs.ruby-lang.org/

Unsubscribe: <mailto:ruby-core-request / ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>