Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > A Revised Rational Proposal

Reply
Thread Tools

A Revised Rational Proposal

 
 
Mike Meyer
Guest
Posts: n/a
 
      12-27-2004
"Dan Bishop" <(E-Mail Removed)> writes:

> Mike Meyer wrote:
>> This version includes the input from various and sundry people.

> Thanks
>> to everyone who contributed.
>>
>> <mike
>>
>> PEP: XXX
>> Title: A rational number module for Python

> ...
>> Implementation
>> ==============
>>
>> There is currently a rational module distributed with Python, and a
>> second rational module in the Python cvs source tree that is not
>> distributed. While one of these could be chosen and made to conform
>> to the specification, I am hoping that several people will volunteer
>> implementatins so that a ''best of breed'' implementation may be
>> chosen.

>
> I'll be the first to volunteer an implementation.


I've already got two implementations. Both vary from the PEP.

> I've made the following deviations from your PEP:
>
> * Binary operators with one Rational operand and one float or Decimal
> operand will not raise a TypeError, but return a float or Decimal.
> * Expressions of the form Decimal op Rational do not work. This is a
> bug in the decimal module.
> * The constructor only accepts ints and longs. Conversions from float
> or Decimal to Rational can be made with the static methods:
> - fromExactFloat: exact conversion from float to Rational
> - fromExactDecimal: exact conversion from Decimal to Rational
> - approxSmallestDenominator: Minimizes the result's denominator,
> given a maximum allowed error.
> - approxSmallestError: Minimizes the result's error, given a
> maximum allowed denominator.
> For example,


Part of finishing the PEP will be modifying the chosen contribution so
that it matches the PEP. As the PEP champion, I'll take that one (and
also write a test module) before submitting the PEP to the pep list
for inclusion and possible finalization.

If you still wish to contribute your code, please mail it to me as an
attachment.

Thanks,
<mike
--
Mike Meyer <(E-Mail Removed)> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
 
Reply With Quote
 
 
 
 
Mike Meyer
Guest
Posts: n/a
 
      12-27-2004
"John Roth" <(E-Mail Removed)> writes:

> I'd suggest making them public rather than either protected or
> private. There's a precident with the complex module, where
> the real and imaginary parts are exposed as .real and .imag.


This isn't addressed in the PEP, and is an oversight on my part. I'm
against making them public, as Rational's should be immutable. Making
the two features public invites people to change them, meaning that
machinery has to be put in place to prevent that. That means either
making all attribute access go through __getattribute__ for new-style
classes, or making them old-style classes, which is discouraged.

If the class is reimplented in C, making them read-only attributes as
they are in complex makes sense, and should be considered at that
time.


<mike
--
Mike Meyer <(E-Mail Removed)> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
 
Reply With Quote
 
 
 
 
Mike Meyer
Guest
Posts: n/a
 
      12-27-2004
Nick Coghlan <(E-Mail Removed)> writes:

> Mike Meyer wrote:
>> Regarding str() and repr() behaviour, Ka-Ping Yee proposes that repr() have
>> the same behaviour as str() and Tim Peters proposes that str() behave like the
>> to-scientific-string operation from the Spec.

>
> This looks like a C & P leftover from the Decimal PEP


Yup. Thank you. This now reads:

Regarding str() and repr() behaviour, repr() will be either
''rational(num)'' if the denominator is one, or ''rational(num,
denom)'' if the denominator is not one. str() will be either ''num''
if the denominator is one, or ''(num / denom)'' if the denominator is
not one.

Is that acceptable?

<mike
--
Mike Meyer <(E-Mail Removed)> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
 
Reply With Quote
 
Steven Bethard
Guest
Posts: n/a
 
      12-27-2004
Mike Meyer wrote:
> "John Roth" <(E-Mail Removed)> writes:
>
>
>>I'd suggest making them public rather than either protected or
>>private. There's a precident with the complex module, where
>>the real and imaginary parts are exposed as .real and .imag.

>
>
> This isn't addressed in the PEP, and is an oversight on my part. I'm
> against making them public, as Rational's should be immutable. Making
> the two features public invites people to change them, meaning that
> machinery has to be put in place to prevent that. That means either
> making all attribute access go through __getattribute__ for new-style
> classes, or making them old-style classes, which is discouraged.


Can't you just use properties?

>>> class Rational(object):

.... def num():
.... def get(self):
.... return self._num
.... return dict(fget=get)
.... num = property(**num())
.... def denom():
.... def get(self):
.... return self._denom
.... return dict(fget=get)
.... denom = property(**denom())
.... def __init__(self, num, denom):
.... self._num = num
.... self._denom = denom
....
>>> r = Rational(1, 2)
>>> r.denom

2
>>> r.num

1
>>> r.denom = 2

Traceback (most recent call last):
File "<interactive input>", line 1, in ?
AttributeError: can't set attribute

Steve
 
Reply With Quote
 
Nick Coghlan
Guest
Posts: n/a
 
      12-27-2004
Mike Meyer wrote:
> Yup. Thank you. This now reads:
>
> Regarding str() and repr() behaviour, repr() will be either
> ''rational(num)'' if the denominator is one, or ''rational(num,
> denom)'' if the denominator is not one. str() will be either ''num''
> if the denominator is one, or ''(num / denom)'' if the denominator is
> not one.
>
> Is that acceptable?


Sounds fine to me.

On the str() front, I was wondering if Rational("x / y") should be an acceptable
string input format.

Cheers,
Nick.

--
Nick Coghlan | http://www.velocityreviews.com/forums/(E-Mail Removed) | Brisbane, Australia
---------------------------------------------------------------
http://boredomandlaziness.skystorm.net
 
Reply With Quote
 
Steve Holden
Guest
Posts: n/a
 
      12-27-2004
Dan Bishop wrote:

> Steven Bethard wrote:
>
>>Dan Bishop wrote:
>>
>>>Mike Meyer wrote:
>>>
>>>>PEP: XXX
>>>
>>>I'll be the first to volunteer an implementation.

>>
>>Very cool. Thanks for the quick work!
>>
>>For stdlib acceptance, I'd suggest a few cosmetic changes:

>
>
> No problem.
>
> """Implementation of rational arithmetic."""
>

[Yards of unusable code]

I'd also request that you change all leading tabs to four spaces!

regards
Steve
--
Steve Holden http://www.holdenweb.com/
Python Web Programming http://pydish.holdenweb.com/
Holden Web LLC +1 703 861 4237 +1 800 494 3119
 
Reply With Quote
 
Skip Montanaro
Guest
Posts: n/a
 
      12-27-2004
Mike> ... or making them old-style classes, which is discouraged.

Since when is use of old-style classes discouraged?

Skip
 
Reply With Quote
 
Steve Holden
Guest
Posts: n/a
 
      12-27-2004
Skip Montanaro wrote:

> Mike> ... or making them old-style classes, which is discouraged.
>
> Since when is use of old-style classes discouraged?
>


Well, since new-style classes came along, surely? I should have thought
the obvious way to move forward was to only use old-style classes when
their incompatible-with-type-based-classes behavior is absolutely required.

Though personally I should have said "use of new-style classes is
encouraged". I agree that there's no real need to change existing code
just for the sake of it, but it would be interesting to see just how
much existing code fails when preceded by the 1.5.2--to-2.4-compatible (?)

__metaclass__ = type

guessing-not-that-much-ly y'rs - steve
--
Steve Holden http://www.holdenweb.com/
Python Web Programming http://pydish.holdenweb.com/
Holden Web LLC +1 703 861 4237 +1 800 494 3119
 
Reply With Quote
 
Mike Meyer
Guest
Posts: n/a
 
      12-27-2004
Nick Coghlan <(E-Mail Removed)> writes:

> Mike Meyer wrote:
>> Yup. Thank you. This now reads:
>> Regarding str() and repr() behaviour, repr() will be either
>> ''rational(num)'' if the denominator is one, or ''rational(num,
>> denom)'' if the denominator is not one. str() will be either ''num''
>> if the denominator is one, or ''(num / denom)'' if the denominator is
>> not one.
>> Is that acceptable?

>
> Sounds fine to me.
>
> On the str() front, I was wondering if Rational("x / y") should be an
> acceptable string input format.


I don't think so, as I don't see it coming up often enough to warrant
implementing. However, Rational("x" / "y") will be an acceptable
string format as fallout from accepting floating point string
representations.

<mike
--
Mike Meyer <(E-Mail Removed)> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
 
Reply With Quote
 
Mike Meyer
Guest
Posts: n/a
 
      12-27-2004
Skip Montanaro <(E-Mail Removed)> writes:

> Mike> ... or making them old-style classes, which is discouraged.
>
> Since when is use of old-style classes discouraged?


I was under the imperssion that old-style classes were going away, and
hence discouraged for new library modules.

However, a way to deal with this cleanly has been suggested by Steven
Bethard, so the point is moot for this discussion.

<mike
--
Mike Meyer <(E-Mail Removed)> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
pair.class revised opalpa@gmail.com opalinski from opalpaweb Java 2 03-16-2006 07:12 PM
A rational proposal Mike Meyer Python 21 12-23-2004 07:17 AM
Re: A rational proposal Jp Calderone Python 1 12-18-2004 07:19 PM
Gradual image fade in (revised) newtohtml@att.net HTML 1 07-19-2004 01:36 PM
Check Out This Great Site (Revised) TechGeekPro MCSE 26 06-29-2004 06:01 AM



Advertisments