[ruby-core:96951] [Ruby master Bug#16518] Should we rationalize Rational's numerator automatically?
From:
eregontp@...
Date:
2020-01-20 09:30:41 UTC
List:
ruby-core #96951
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>