[ruby-core:25675] [Bug #2121] mathn/rational destroys Fixnum#/, Fixnum#quo and Bignum#/, Bignum#quo

Issue #2121 has been updated by Run Paint Run Run.


I agree that _mathn_ constitutes a problem, but due to the means it employs rather than the end it achieves. In Ruby 1.8 the expectation is that '/' performs integer division, and having such a fundamental be subverted is untenable. 

However, under Ruby 1.9, where Rational is a native class, it is altogether more reasonable that, by default, the '/' method coerce to Rational (as Lisp), preferably, or Float (as Perl and Python 3) when necessary.

GvR rationalizes (pun unintentional) his decision to have Python 3 perform mathematical division by default, in contrast to Python 2.0 which behaves as Ruby sans _mathn_, as follows:
  
"When you write a function implementing a numeric algorithm (for example, calculating the phase of the moon) you typically expect the arguments to be specified as floating point numbers. However, since Python doesn’t have type declarations, nothing is there to stop a caller from providing you with integer arguments. In a statically typed language, like C, the compiler will coerce the arguments to floats, but Python does no such thing – the algorithm is run with integer values until the wonders of mixed-mode arithmetic produce intermediate results that are floats."

"For everything except division, integers behave the same as the corresponding floating point numbers. For example, 1+1 equals 2 just as 1.0+1.0 equals 2.0, and so on. Therefore one can easily be misled to expect that numeric algorithms will behave regardless of whether they execute with integer or floating point arguments. However, when division is involved, and the possibility exists that both operands are integers, the numeric result is silently truncated, essentially inserting a potentially large error into the computation. Although one can write defensive code that coerces all arguments to floats upon entry, this is tedious, and it doesn’t enhance the readability or maintainability of the code. Plus, it prevents the same algorithm from being used with complex arguments (although that may be highly special cases)."

<http://python-history.blogspot.com/2009/03/problem-with-integer-division.html>

 http://research.microsoft.com/en-us/um/people/daan/download/papers/divmodnote.pdf and http://python.org/dev/peps/pep-0238/ are also relevant.
----------------------------------------
http://redmine.ruby-lang.org/issues/show/2121

----------------------------------------
http://redmine.ruby-lang.org