From: eregontp@...
Date: 2020-01-20T09:30:41+00:00
Subject: [ruby-core:96951] [Ruby master Bug#16518] Should we rationalize Rational's numerator automatically?

Issue #16518 has been updated by Eregon (Benoit Daloze).

Assignee set to mrkn (Kenta Murata)

This seems due to the fact `Rational(BigDecimal, Integer)` does not return a Rational but a BigDecimal!

That seems highly surprising to me, any `Foo()` "constructor" should return a `Foo`, isn't it?

Also a `Float` as numerator correctly produces a Rational, so the bug seems to be with BigDecimal as a numerator:
```ruby
> Rational(BigDecimal(1), 2).class
=> BigDecimal
> Rational(BigDecimal(1).to_f, 2).class
=> Rational
```

----------------------------------------
Bug #16518: Should we rationalize Rational's numerator automatically?
https://bugs.ruby-lang.org/issues/16518#change-83980

* Author: st0012 (Stan Lo)
* Status: Open
* Priority: Normal
* Assignee: mrkn (Kenta Murata)
* Target version: 
* ruby -v: 2.6.5
* Backport: 2.5: UNKNOWN, 2.6: UNKNOWN, 2.7: UNKNOWN
----------------------------------------
In this [Rails issue](https://github.com/rails/rails/issues/38041) we found that using `BigDecimal` as a `Rational`'s numerator can have inconsistent behaviors when the denominator gets bigger. For example:

```
> 1 == BigDecimal(1)
=> true
> Rational(1, 1) == Rational(BigDecimal(1), 1)
=> true
> Rational(1, 6) == Rational(BigDecimal(1), 6)
=> true
> Rational(1, 60) == Rational(BigDecimal(1), 60)
=> false
```


So my question is, is this behavior expected? 
If it's not expected, do we have a plan to fix it?
If it is, does it make sense to manually rationalize the numerator before passing it into the `Rational` call, in order to get a consistent result?



-- 
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>