Agreed. Rational arithmetic was the default "exact" arithmetic in ABC and it did not work out as expected.
On 6/17/05, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > > These PEPs are four years old. Nothing is intrinsically wrong with them, > but they have garnered little enthusiasm, discussion, or support, suggesting > that the original need was somewhat modest. > > In addition, the principal (but not only) use cases for a builtin rational > type and corresponding rational literal have already been addressed by the > decimal module (and the expected future integration of decimal literals). > From rationale section of the PEPs: > > """ > Rational numbers are useful for exact and unsurprising arithmetic. They > give the correct results people have been taught in various math classes. > Making the "obvious" non-integer type one with more predictable semantics > will surprise new programmers less than using floating point numbers. As > quite a few posts on c.l.py and on tutor@python.org have shown, people often > get bit by strange semantics of floating point numbers: for example, > round(0.98, 2) still gives 0.97999999999999998. > """ > > The future direction of the decimal module likely entails literals in the > form of 123.45d with binary floats continuing to have the form 123.45. This > conflicts with the rational literal proposal of having 123.45 interpreted as > 123 + 45/100. > > There may still be a use for a rational module in the standard library, but > builtin support is no longer needed or desirable. > > The PEPs also touch on division ambiguities which were largely resolved by > the acceptance of PEP 238 which introduced the floor division operator and > from __future__ import division. > > The rational proposal also has an intrinsic weakness shared with Java's > prior versions of BigDecimal which they found to be unworkable in practice. > The weakness was that repeated operations caused the internal number of > digits to grow beyond reason. For this reason, the PEP proposes some > arbitrary level of truncation which conflicts with the goals of having > "obvious and exact" arithmetic. The proposed truncation methodology was > undeveloped and made no proposal for the same fine level of control as its > counterpart in the decimal module where issues of variable precision, > multiple contexts, and alternate rounding modes have been fully thought out. > > > > Raymond > > > > > _______________________________________________ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/guido%40python.org > > > -- --Guido van Rossum (home page: http://www.python.org/~guido/) _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com