Adifferent PEP suggests adding a builtin rational type toPython. This PEP suggests changing the ddd.ddd float literal to arational in Python, and modifying non-integer division to returnit.
This PEP is rejected. The needs outlined in the rationale sectionhave been addressed to some extent by the acceptance ofPEP 327for decimal arithmetic. Guido also noted, “Rational arithmeticwas the default ‘exact’ arithmetic in ABC and it did not work out asexpected”. See the python-dev discussion on 17 June 2005[1].
Rational numbers are useful for exact and unsurprising arithmetic.They give the correct results people have been taught in variousmath classes. Making the “obvious” non-integer type one with morepredictable semantics will surprise new programmers less thanusing floating point numbers. As quite a few posts on c.l.py andontutor@python.org have shown, people often get bit by strangesemantics of floating point numbers: for example,round(0.98,2)still gives 0.97999999999999998.
Literals conforming to the regular expression'\d*.\d*' will berational numbers.
The only backwards compatible issue is the type of literalsmentioned above. The following migration is suggested:
from__future__importrational_literalsto cause all such literals to be treated as rational numbers.__future__ statement. Thewarning message will contain information about the__future__statement, and indicate that to get floating point literals,they should be suffixed with “e0”.Rationals are slow and memory intensive!(Relax, I’m not taking floats away, I’m just adding two more characters.1e0 will still be a float)
Rationals must present themselves as a decimal float or they will behorrible for users expecting decimals (i.e.str(.5) should return'.5' andnot'1/2'). This means that many rationals must be truncated at somepoint, which gives us a new loss of precision.
This document has been placed in the public domain.
Source:https://github.com/python/peps/blob/main/peps/pep-0240.rst
Last modified:2025-02-01 08:55:40 GMT