John Roth [EMAIL PROTECTED] writes:
Mike Meyer [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Nick Coghlan [EMAIL PROTECTED] writes:
Mike Meyer wrote:
Yup. Thank you. This now reads:
Regarding str() and repr() behaviour, repr() will be either
''rational(num)'' if the
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
Title: RE: A Revised Rational Proposal
[Mike Meyer]
#- When combined with a floating type - either complex or float - or a
#- decimal type, the result will be a TypeError. The reason for this is
#- that floating point numbers - including complex - and decimals are
#- already imprecise
Title: RE: A Revised Rational Proposal
[Dan Bishop]
#- I disagree with raising a TypeError here. If, in mixed-type
#- expressions, we treat ints as a special case of rationals, it's
#- inconsistent for rationals to raise TypeErrors in situations
#- where int
#- doesn't.
I think it never
Title: RE: A Revised Rational Proposal
[Dan Bishop]
#- * Binary operators with one Rational operand and one float or Decimal
#- operand will not raise a TypeError, but return a float or Decimal.
I think this is a mistake. Rational should never interact with float.
#- * Expressions
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
Mike ... or making them old-style classes, which is discouraged.
Since when is use of old-style classes discouraged?
Skip
--
http://mail.python.org/mailman/listinfo/python-list
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
Nick Coghlan [EMAIL PROTECTED] 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
Skip Montanaro [EMAIL PROTECTED] 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
Title: RE: A Revised Rational Proposal
[Mike Meyer]
#- 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.
Remember
Mike Meyer [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Nick Coghlan [EMAIL PROTECTED] 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
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
...
Implicit Construction
-
When combined with a floating type - either complex or float
Dan Bishop [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
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
...
Implicit Construction
-
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
Dan Bishop wrote:
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
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:
Use PEP 257[1] docstring conventions, e.g. triple-quoted strings.
Use PEP 8[2] naming conventions, e.g.
Steven Bethard [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
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:
Use PEP 257[1] docstring
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.
from
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 :)
Otherwise, looks good.
Dan Bishop wrote:
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
...
Implicit Construction
-
When combined with a floating type - either complex or
Dan Bishop [EMAIL PROTECTED] 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
John Roth [EMAIL PROTECTED] 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
Nick Coghlan [EMAIL PROTECTED] 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
Mike Meyer wrote:
John Roth [EMAIL PROTECTED] 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
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
Version: $Revision: 1.4 $
Last-Modified: $Date: 2003/09/22 04:51:50 $
Author: Mike Meyer [EMAIL PROTECTED]
Status: Draft
Type:
Mike Meyer wrote:
Well, you want to be able to add floats to rationals. The results
shouldn't be rational, for much the same reason as you don't want to
convert floats to rationals directly. I figure the only choice that
leaves is that the result be a float. That and float(rational) should
be the
Nick Coghlan [EMAIL PROTECTED] writes:
Actually, I was misremembering how Decimal worked - it follows the rule you
suggest:
float() + Decimal() fails with a TypeError
float() + float(Decimal()) works fine
And I believe Decimal's __float__ operation is a 'best effort' kind of
thing, so I
Mike Meyer wrote:
Actually, I suggested that:
float() + Rational() returns float
You're suggesting that the implicit conversion to float not happen
here, and the user be forced to cast it to float? And you're saying
Decimal does it that way.[
Yup.
I had another look at PEP 327 (the section on
Mike Meyer wrote:
I'm willing to do the work to get
decimals working properly with it.
Facundo's post reminded me of some of the discussion about the interaction
between floats and Decimal that went on when he was developing the module that
eventually made it into the standard library.
Perhaps
Nick Coghlan [EMAIL PROTECTED] writes:
Mike Meyer wrote:
I'm willing to do the work to get
decimals working properly with it.
Facundo's post reminded me of some of the discussion about the
interaction between floats and Decimal that went on when he was
developing the module that
I've been thinking about doing this for a while. cRat
(http://sf.net/projects/pythonic) already meets these qualifications
except that I need to add decimal support to it now that decimals are
in the language. I could rewrite the existing code in Python (it's
currently in C), but there are some
On Fri, 17 Dec 2004 21:29:52 -0600, Mike Meyer [EMAIL PROTECTED] wrote:
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 [EMAIL PROTECTED]
Status: Draft
Type: Staqndards
Content-Type: text/x-rst
Created:
Mike Meyer wrote:
John Roth [EMAIL PROTECTED] writes:
Mike Meyer [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
PEP: XXX
Title: A rational number module for Python
...
Rationals will mix with all other numeric types. When combined
with an
integer type, that integer will
Title: RE: A rational proposal
[Mike Meyer]
#- 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)?
To convert a Decimal
[Batista, Facundo]
To convert a Decimal to Rational, [...]
Hi, people. I am not closely following this thread and do not know if this
has been discussed before. Sorry if I'm repeating known arguments...
Decimal to Rational is easy. The interesting problem is how to best
convert a float to
[EMAIL PROTECTED] (Christopher A. Craig) writes:
I've been thinking about doing this for a while. cRat
(http://sf.net/projects/pythonic) already meets these qualifications
except that I need to add decimal support to it now that decimals are
in the language. I could rewrite the existing
Raymond L. Buvel wrote:
gmpy wraps GMP, which is covered by LGPL; therefore, gmpy itself is
LGPL, and thus, sadly, cannot be included with python (otherwise,
speaking as gmpy's author, I'd be glad to fix its design to meet your
objections).
Since the LGPL was designed to allow propritary
Hi Mike - Thanks for taking the time to put this together.
In article [EMAIL PROTECTED], Mike Meyer wrote:
- max(*args): return the largest of a list of numbers and self.
- min(*args): return the smallest of a list of numbers and self.
I would strongly prefer either adapting the already
Mike Meyer wrote:
PEP: XXX
Title: A rational number module for Python
snip
I think it is a good idea to have rationals as part of the standard
distribution but why not base this on the gmpy module
(https://sourceforge.net/projects/gmpy)? That module already provides
good performance. However,
Raymond L. Buvel [EMAIL PROTECTED] writes:
Mike Meyer wrote:
PEP: XXX
Title: A rational number module for Python
snip
I think it is a good idea to have rationals as part of the standard
distribution but why not base this on the gmpy module
(https://sourceforge.net/projects/gmpy)? That
John Roth [EMAIL PROTECTED] writes:
Mike Meyer [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
PEP: XXX
Title: A rational number module for Python
The ``Rational`` class shall define all the standard mathematical
operations: addition, subtraction, multiplication, division, modulo
On Sat, 18 Dec 2004 12:29:10 -0600, Mike Meyer [EMAIL PROTECTED] wrote:
Raymond L. Buvel [EMAIL PROTECTED] writes:
Mike Meyer wrote:
PEP: XXX
Title: A rational number module for Python
snip
I think it is a good idea to have rationals as part of the standard
distribution but why not
On Sat, 18 Dec 2004 12:40:04 -0600, Mike Meyer [EMAIL PROTECTED] wrote:
John Roth [EMAIL PROTECTED] writes:
Mike Meyer [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
PEP: XXX
Title: A rational number module for Python
The ``Rational`` class shall define all the standard
Raymond L. Buvel [EMAIL PROTECTED] wrote:
Mike Meyer wrote:
PEP: XXX
Title: A rational number module for Python
snip
I think it is a good idea to have rationals as part of the standard
distribution but why not base this on the gmpy module
(https://sourceforge.net/projects/gmpy)?
[EMAIL PROTECTED] (Alex Martelli) writes:
gmpy wraps GMP, which is covered by LGPL; therefore, gmpy itself is
LGPL, and thus, sadly, cannot be included with python (otherwise,
speaking as gmpy's author, I'd be glad to fix its design to meet your
objections).
There's no obstacle to including
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 [EMAIL PROTECTED]
Status: Draft
Type: Staqndards
Content-Type: text/x-rst
Created: 16-Dec-2004
Python-Version: 2.5
Post-History: 30-Aug-2002
Abstract
Mike Meyer wrote:
Last-Modified: $Date: 2003/09/22 04:51:50 $
Created: 16-Dec-2004
Post-History: 30-Aug-2002
playing with the time machine?
/F
--
http://mail.python.org/mailman/listinfo/python-list
48 matches
Mail list logo
