From: elct9620+ruby@... Date: 2020-01-22T09:27:16+00:00 Subject: [ruby-core:96967] [Ruby master Bug#16518] Should we rationalize Rational's numerator automatically? Issue #16518 has been updated by elct9620 (Zheng Xian Qiu). After a quick trace of the source code, the problem is BigDecimal is a subclass of Numeric. The `nurat_conver` method check for argument type and convert to Rational, but the Numeric doesn't. Ref: https://github.com/ruby/ruby/blob/5275d8bf4c43db9f057d24a26cf33ecd69f8b345/rational.c#L2632 When it calls the `f_div` method, it calculates it directly without converting them to Rational. We can simply force convert the result, but I didn't think it is the best way: ``` return to_rational(f_div(a1, a2)); ``` ---------------------------------------- Bug #16518: Should we rationalize Rational's numerator automatically? https://bugs.ruby-lang.org/issues/16518#change-83992 * 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: