Re: A rational proposal

From: Mike Meyer (mwm_at_mired.org)
Date: 12/18/04 

Date: Sat, 18 Dec 2004 12:40:04 -0600

"John Roth" <newsgroups@jhrothjr.com> writes:

> "Mike Meyer" <mwm@mired.org> wrote in message
> news:864qik472n.fsf@guru.mired.org...
>> PEP: XXX
>> Title: A rational number module for Python
>> 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.

They don't handle decimals or rationals. This is following the lead of
the decimal package.

>> - 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.

Good point. Currently, objects now how to convert themselves to int,
float and complex. Should Rational now how to convert itself to
Decimal (and conversely, decimal now how to convert itself to
Rational)?

>> - inv(): Return the inverse of self.
> I presume this means that if the rational is x/y, then it
> returns y/x?

Is this better wording:
- inv(): Return self to the power -1.

>> 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.

I'm of two minds about this one. One is that decimals have limited
precision. But they represent their values exactly, whereas 1E73 isn't
a 1 followed by 73 zeros when converted to an int. On the other hand,
every decimal has a rational equivalent, but not vice versa.

      Thanks,
      <mike 

-- 
Mike Meyer <mwm@mired.org>			http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.

Relevant Pages

  • Re: Precision issue
    ... Can the float handling rules of the underlying layers be ... scaling by 100 is overkill - the nearest power of two is ... should be sufficient to allow two decimal digits of precision. ... One common need for decimals is for currency values. ...
    (comp.lang.python)
  • Re: off topic but please forgive me me and answer
    ... need to avoid floats and decimals and use Fractions: ... both float and Decimal are fixed precision numbers. ... Only Fraction gives exact ...
    (comp.lang.python)
  • Re: off topic but please forgive me me and answer
    ... need to avoid floats and decimals and use Fractions: ... both float and Decimal are fixed precision numbers. ... Only Fraction gives exact ...
    (comp.lang.python)
  • Re: floating-point precision
    ... The first 6 decimals are ok, ... type float just doesn't provide the precision you ...
    (comp.lang.c)
  • Re: demonic problem descriptions
    ... floating point, fixed point, and rationals. ... decimals, at least as the default input/output format. ... arithmetic that are better than converting to fractions first. ...
    (comp.lang.lisp)