A rational proposal
newsgroups at jhrothjr.com
Sat Dec 18 19:07:17 CET 2004
"Mike Meyer" <mwm at mired.org> wrote in message
news:864qik472n.fsf at guru.mired.org...
> PEP: XXX
> Title: A rational number module for Python
> Version: $Revision: 1.4 $
> Last-Modified: $Date: 2003/09/22 04:51:50 $
> Author: Mike Meyer <mwm at mired.org>
> Status: Draft
> Type: Staqndards
> Content-Type: text/x-rst
> Created: 16-Dec-2004
> Python-Version: 2.5
> Post-History: 30-Aug-2002
> This PEP proposes a rational number module to add to the Python
> standard library.
> The ``Rational`` class shall define all the standard mathematical
> operations: addition, subtraction, multiplication, division, modulo
> and power. It will also provide the methods:
> - max(*args): return the largest of a list of numbers and self.
> - min(*args): return the smallest of a list of numbers and self.
max() and min() are already part of the standard library.
Providing them as instance methods is quite irregular.
> - decimal(): return the decimal approximation to the rational in the
> current context.
This ought to be the responsibility of the decimal() constructor.
I can see including it here to avoid adding it to the decimal()
constructor, but IMO it's bad design.
> - inv(): Return the inverse of self.
I presume this means that if the rational is x/y, then it
> Rationals will mix with all other numeric types. When combined with an
> integer type, that integer will be converted to a rational before the
> operation. When combined with a floating type - either complex or
> float - the rational will be converted to a floating approximation
> before the operation, and a float or complex will be returned. The
> reason for this is that floating point numbers - including complex -
> are already imprecise. To convert them to rational would give an
> incorrect impression that the results of the operation are
> precise. Decimals will be converted to rationals before the
> operation. [Open question: is this the right thing to do?]
I'd prefer to have rationals converted to decimals before
the operation, for the same reason that they're converted
to floats. Decimals also have limited precision.
> Rationals can be converted to floats by float(rational), and to
> integers by int(rational).
If this is the case, then there is no reason to have a separate
member operation to convert rationals to decimal. Consistency
says to do it the same way for all similar operations.
More information about the Python-list