Here's the third installment -- my response to Moshe's rational numbers PEP. I believe that a fourth PEP should be written as well: decimal floating point. Maybe Tim can draft this? > PEP: XXX > Title: Adding a Rational Type to Python > Version: $Revision$ > Author: pep@zadka.site.co.il (Moshe Zadka) > Status: Draft > Python-Version: 2.2 > Type: Standards Track > Created: 11-Mar-2001 > Post-History: > > > Abstract > > Python has no number type whose semantics are that of a > unboundedly precise rational number. But one could easily be added to the standard library, and several implementations exist, including one in the standard distribution: Demo/classes/Rat.py. > This proposal explains the > semantics of such a type, and suggests builtin functions and > literals to support such a type. In addition, if division of > integers would return a non-integer, it could also return a > rational type. It's kind of sneaky not to mention in the abstract that this should be the default representation for numbers containing a decimal point, replacing most use of floats! > Rationale > > While sometimes slower and more memory intensive (in general, > unboundedly so) rational arithmetic captures more closely the > mathematical ideal of numbers, and tends to have behaviour which > is less surprising to newbies, This PEP definitely needs a section of arguments Pro and Con. For Con, mention at least that rational arithmetic is much slower than floating point, and can become *very* much slower when algorithms aren't coded carefully. Now, naively coded algorithms often don't work well with floats either, but there is a lot of cultural knowledge about defensive programming with floats, which is easily accessible to newbies -- similar information about coding with rationals is much less easily accessible, because no mainstream languages have used rationals before. (I suppose Common Lisp has rationals, since it has everything, but I doubt that it uses them by default for numbers with a decimal point.) > RationalType > > This will be a numeric type. The unary operators will do the > obvious thing. Binary operators will coerce integers and long > integers to rationals, and rationals to floats and complexes. > > The following attributes will be supported: .numerator, > .denominator. The language definition will not define other > then that > > r.denominator * r == r.numerator > > In particular, no guarantees are made regarding the GCD or the > sign of the denominator, even though in the proposed > implementation, the GCD is always 1 and the denominator is > always positive. > > The method r.trim(max_denominator) will return the closest > rational s to r such that abs(s.denominator) <= max_denominator. > > The rational() Builtin > > This function will have the signature rational(n, d=1). n and d > must both be integers, long integers or rationals. A guarantee > is made that > > rational(n, d) * d == n > > Literals > > Literals conforming to the RE '\d*.\d*' will be rational numbers. > > Backwards Compatability > > The only backwards compatible issue is the type of literals > mentioned above. The following migration is suggested: > > 1. from __future__ import rational_literals will cause all such > literals to be treated as rational numbers. > 2. Python 2.2 will have a warning, turned off by default, about > such literals in the absence of such an __future__. The > warning message will contain information about the __future__ > statement, and that to get floating point literals, they > should be suffixed with "e0". > 3. Python 2.3 will have the warning turned on by default. This > warning will stay in place for 24 months, at which time the > literals will be rationals and the warning will be removed. There are also backwards compatibility issues at the C level. Question: the time module's time() function currently returns a float. Should it return a rational instead? This is a trick question. > Copyright > > This document has been placed in the public domain. > > > > Local Variables: > mode: indented-text > indent-tabs-mode: nil > End: --Guido van Rossum (home page: http://www.python.org/~guido/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4