Issue #5179 has been updated by mame (Yusuke Endoh).


We discussed #5321 at the dev-meeting.  Whether a value is exact or inexact, is not decidable based on a class.  For example, a literal `0.0` may be considered as precise and exact.  But, if the same value is gained from an inaccurate calculation, it may be considered as inexact.

In regard to this paricular issue, Naruse pointed out that we already have `Float#to_r`.  So I think that it is reasonable that `Complex(1, 0.0).to_r` returns `Rational(1, 1)` instead of RangeError.

----------------------------------------
Bug #5179: Complex#rationalize and to_r with approximate zeros
https://bugs.ruby-lang.org/issues/5179#change-83939

* Author: marcandre (Marc-Andre Lafortune)
* Status: Assigned
* Priority: Normal
* Assignee: mrkn (Kenta Murata)
* Target version: 
* ruby -v: r32354
* Backport: 
----------------------------------------
Currently, Complex#rationalize and Complex#to_r raise a RangeError if the imaginary part is nonzero *or is a Float*. Note that a BigDecimal(0) is accepted, though:

    Complex(1, 0).to_r                 # => Rational(1,1)
    Complex(1, BigDecimal("0.0")).to_r # => Rational(1,1)
    Complex(1, 0.0).to_r               # => RangeError

This is inconsistent. I recommend not raising an error for 0.0 (Float or BigDecimal). Any objection?




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