[Python-Dev] Propose rejection of PEPs 239 and 240 -- a builtin rational type and rational literals
Guido van Rossum
gvanrossum at gmail.com
Fri Jun 17 20:28:57 CEST 2005
Agreed. Rational arithmetic was the default "exact" arithmetic in ABC
and it did not work out as expected.
On 6/17/05, Raymond Hettinger <raymond.hettinger at verizon.net> 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 at 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.
> Python-Dev mailing list
> Python-Dev at python.org
--Guido van Rossum (home page: http://www.python.org/~guido/)
More information about the Python-Dev