Mark Dickinson added the comment:
staticmethod substituted for classmethod in r60712.
I'm not sure I like the idea of names Rational and Fraction; the two
classes numbers.Rational and rational.Rational are quite different beasts,
and using two almost-synonyms for their names seems like a bad
Mark Dickinson added the comment:
We still need to sort out the trim/approximate/convergents decisions.
Currently, we have:
from_continued_fraction
to_continued_fraction
approximate (what we've been calling trim: limit the denominator)
At this point I'm not sure how much I care about
Guido van Rossum added the comment:
I'm not sure I like the idea of names Rational and Fraction; the two
classes numbers.Rational and rational.Rational are quite different beasts,
and using two almost-synonyms for their names seems like a bad idea.
Is there some more descriptive name for
Mark Dickinson added the comment:
Fair enough. Should it be fractions.Fraction or fraction.Fraction?
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1682
__
___
Python-bugs-list
Guido van Rossum added the comment:
Fair enough. Should it be fractions.Fraction or fraction.Fraction?
I think from fractions import Fraction is linguistically more
correct -- the concept is always mentioned in plural, but a fractional
number is of course singular. We also have numbers.
Guido van Rossum added the comment:
Go for it!
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1682
__
___
Python-bugs-list mailing list
Unsubscribe:
Mark Dickinson added the comment:
Any reason not to make the name change? Is further discussion/time
required, or can we go ahead and rename Rational to Fraction and
rational.py to fractions.py? It seems like everybody's happy with the
idea.
I note that the name change affects
Mark Dickinson added the comment:
Guido:
Correct -- the thing is that you can't know the signature of the
subclass's constructor so you can't very well blindly call that.
Jeffrey, is it okay for me to change the three class methods
(from_float, from_decimal, from_continued_fraction) to
Guido van Rossum added the comment:
Jeffrey:
Yay for measurements!
I was going to say that __add__ is inefficient because it makes so
many function calls, but it turns out that, as you say, the cost of
constructing a new Rational instance drowns everything else. On my
2.8GHz iMac,
Jeffrey Yasskin added the comment:
Mark: Coming from C++, I don't have any intuition on static vs. class
methods. It might be strange to write MyRationalSubclass.from_float()
and get a Rational back, but it might also be strange to write a
subclass with a different constructor and get an error.
Jeffrey Yasskin added the comment:
I figured I'd time the difference before we change the code:
$ ./python.exe -m timeit -s 'import rational; r=rational.Rational(3, 1)'
'r.numerator'
100 loops, best of 3: 0.696 usec per loop
$ ./python.exe -m timeit -s 'import rational;
Mark Dickinson added the comment:
from Guido:
I have one minor nit on the current rational.py code: all internal
accesses to the numerator and denominator should use self._numerator
and self._denominator -- going through the properties makes it *much*
slower. Remember that Python
Facundo Batista added the comment:
I'm +0 to make Decimal(Rational(x,y)) available.
I'd make it something like:
Decimal(R) == Decimal(R.numerator) / Decimal(R.denominator)
Note, as Raymond says, that this division implies the use of the
context. So the following will NOT be true:
R ==
Guido van Rossum added the comment:
FWIW, if Rational(Decimal(...)) is to be accepted, then
Decimal(Rational(...)) should also be accepted, and arguably mixed
binary operations as well (Rational(...) + Decimal(...) etc.).
--
assignee: gvanrossum - jyasskin
Raymond Hettinger added the comment:
I would rather drop it than see that mess.
FWIW, there is a difference. Rational(Decimal(...)) takes place
without reference to a decimal.Context and is always lossless.
In contrast, Decimal(Rational(...)) is context sensitive (the division
is subject
Mark Dickinson added the comment:
About Rational('3.') and Rational('.2'):
It's not so much to do with consistency with float and Decimal; more to do
with the fact that some people like to write floats these ways (which
presumably is why float and Decimal allow such input).
It occurs to me
Mark Dickinson added the comment:
Regex changed in r60530.
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1682
__
___
Python-bugs-list mailing list
Unsubscribe:
Jeffrey Yasskin added the comment:
I think '1e+100' would constitute feature creep at this point, but
thanks for the suggestion, and the improvement in the readability of the
regex!
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1682
Raymond Hettinger added the comment:
The rational constructor should accept decimals directly.
Rational(Decimal('3.1')) does not suffer the same representation error
problems as Rational(float('3.1')). The conversion from decimal is
lossless and does not depend on the decimal context. There
Jeffrey Yasskin added the comment:
I think Rational should handle all floating types as consistently as
possible, whatever their radix or precision. It's unlikely that people
will convert from them often anyway, especially from Decimal, so the
shorter conversion from Decimal doesn't seem to
Jeffrey Yasskin added the comment:
Whoops, sorry for taking a while to answer. +0 on adding support for
'2.' and '.3', given that they're allowed for float and Decimal. Not +1
because they'll make the regular expression more complicated, and
they're not exactly necessary, but if you want to add
Mark Dickinson added the comment:
I noticed that the ability to type Rational(2.3) has been added (and I
think this is a very useful addition). One minor nit: would it make
sense to have Rational(2.) and Rational(.3) also work? These strings
work for float() and Decimal(), and 2. and .3
Jeffrey Yasskin added the comment:
I coulda sworn I looked for is_nan and is_infinite. Oh well, switched to
using .is_finite, which is even better and checked in as r60068. Thanks
for the pointer.
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1682
Mark Dickinson added the comment:
Raymond:
Were the new methods part of the spec update? If so that's great.
Yes. See http://www2.hursley.ibm.com/decimal/damisc.html
If not, we need to take them out. We want zero API creep that isn't
mandated by the spec (no playing fast and loose
Raymond Hettinger added the comment:
Were the new methods part of the spec update? If so that's great. If
not, we need to take them out. We want zero API creep that isn't
mandated by the spec (no playing fast and loose with this module).
__
Tracker [EMAIL
Mark Dickinson added the comment:
(About the latest patch): this all looks good to me.
The comment that Decimal provides no other public way to detect nan and
infinity. is not
true (though it once was). Decimal has public methods is_nan and is_infinite,
added as
part of updating to the
Jeffrey Yasskin added the comment:
Here's a patch that adds construction from strings (Guido favored them)
and .from_decimal(), changes __init__ to __new__ to enforce
immutability, and removes rational. from repr and the parens from str.
I don't expect this to be contentious, so I'll commit it
Jeffrey Yasskin added the comment:
After this come the two approximation methods. Both are implemented
using the continued fraction representation of the number:
http://en.wikipedia.org/wiki/Continued_fraction#Best_rational_approximations.
The first, currently named trim, takes the closest
Mark Dickinson added the comment:
Inexact is saying that one thing could be ==3 and the other ==0, so I
think it's correct.
You're right, of course :)
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1682
__
Jeffrey Yasskin added the comment:
Thanks! I've added some minimal documentation and construction from
other Rationals. The other formats for string parsing center around
where whitespace is allowed, and whether you can put parens around the
whole fraction. Parens would, of course, go away if
Jeffrey Yasskin added the comment:
_binary_float_to_ratio: Oops, fixed.
Rational() now equals 0, but I'd like to postpone Rational('3/2') until
there's a demonstrated need. I don't think it's as common a use as
int('3'), and there's more than one possible format, so some real world
experience
Mark Dickinson added the comment:
The latest version of rational.py looks good to me---nice work! (I haven't
looked properly at
numbers.py or test_rational.py, yet. I do plan to, eventually.)
I do think it's important to be able to create Rational instances from strings:
e.g., for
easy
Mark Dickinson added the comment:
Just had a quick look at numbers.py. Only two comments:
1. I think there's a typo in the docstring for Inexact: one of those == should
be a !=
2. Not that it really matters now, but note that at least for Decimal, x-y is
not the same
as x+(-y) (I'm
Jeffrey Yasskin added the comment:
If the consensus is that Decimal should not implement Real, I'll reply
to that thread and withdraw the patch.
Raymond, do you want me to add Decimal.__init__(Rational) in this patch
or another issue/thread?
I don't understand the comment about scaling down
Raymond Hettinger added the comment:
If the consensus is that Decimal should not implement Real,
I'll reply to that thread and withdraw the patch.
Thanks. That would be nice.
Raymond, do you want me to add Decimal.__init__(Rational)
in this patch
How about focusing on the rational module
Mark Dickinson added the comment:
More comments, questions, and suggestions on the latest patch:
1. In _binary_float_to_ratio, the indentation needs adjusting. Also 'top = 0L'
could be replaced with 'top =
0', unless you need this code to work with Python 2.3 and earlier, in which
case top
Mark Dickinson added the comment:
About .trim and .approximate:
it sounds like these are different, but quite closely related, methods: one
takes a positive
integer and returns the best approximation with denominator bounded by that
integer; the other
returns the 'smallest' rational in
Guido van Rossum added the comment:
Would it be reasonable then to not have any of the numeric tower stuff
put in the decimal module -- basically leave it alone (no __ceil__,
etc)?
If that's the preference of the decimal developers, sure.
__
Tracker [EMAIL
Raymond Hettinger added the comment:
FWIW, I'm -1 on moving this module to the standard library. There has
been basically *zero* demand for something like this. Because rational
implementations seem to be more fun to write than to use, I think there
are some competing implementations.
Guido van Rossum added the comment:
Raymond, do you *always* have to be such a grinch?
The mere existance of competing implementations proves that there's a
need. Hopefully having one in the stdlib will inspire others to
contribute improvements rather than starting from scratch.
Raymond Hettinger added the comment:
Not sure I'm the grinch on this one. I thought PEPs on this were
rejected long ago and no one complained afterwards. After years of
watching newsgroup discussions and feature requests, I do not recall a
single request or seeing a single problem that was
Facundo Batista added the comment:
The PEP 239 is Rejected (http://www.python.org/dev/peps/pep-0239/).
If a Rational data type would be included in the stdlib, my
recommendation is that first that PEP would be reopened and pushed until
get accepted.
Also, note the kind of questions Mark is
Guido van Rossum added the comment:
The rejection of PEP 239 was years ago. PEP 3141 was accepted; it
includes adding a rational type to the stdlib, and Jeffrey is doing this
with my encouragement.
The motivation is to have at least one example of each type in our
modest numeric tower in the
Raymond Hettinger added the comment:
If this goes in, I have some recommendations:
* Follow the decimal module's lead in assiduously avoiding
float-rational conversions. Something like Rat.from_float(1.1) is
likely to produce unexpected results (like locking in an inexact input
and having an
Facundo Batista added the comment:
2008/1/9, Raymond Hettinger said:
* Consider adding Decimal.from_rational and Rational.from_decimal. I
believe these are both easy and can be done losslessly.
If it's lossless, why not just allow Decimal(Rational(...)) and
Rational(Decimal(...))?
Raymond Hettinger added the comment:
If it's lossless, why not just allow
Decimal(Rational(...)) and Rational(Decimal(...))?
Those conversions are fine.
It's the float--rational conversions that are problematic. There are
exact float to rational conversions using math.frexp() but I don't
Guido van Rossum added the comment:
On Jan 9, 2008 4:29 PM, Raymond Hettinger [EMAIL PROTECTED] wrote:
I think the history of rational modules is that simplistic
implementations get built and then the writers find that exploding
denominators limit their usefulness for anything other than
Jeffrey Yasskin added the comment:
* Follow the decimal module's lead in assiduously avoiding
float-rational conversions. Something like Rat.from_float(1.1) is
likely to produce unexpected results (like locking in an inexact input
and having an unexpectedly large denominator).
I agree that
Raymond Hettinger added the comment:
Decimal.from_rational(Rat(1, 3)) wouldn't be lossless
It should be implemented as Decimal(1)/Decimal(3) and then let the
context handle any inexactness.
Rational.from_decimal is easier than from_float.
Yes. Just use Decimal.as_tuple() to get the integer
Raymond Hettinger added the comment:
One other thought, the Decimal and Rational constructors can be made to
talk to each other via a magic method so that neither has to import the
other (somewhat like we do now with __int__ and __float__).
__
Tracker [EMAIL
Mark Dickinson added the comment:
Allowing automatic coercion to and from Decimal sounds dangerous and
complicated to me. Mightn't it be safer just to disallow this (at least for
now)?
I think something like trim() (find the closest rational approximation with
denominator bounded by a
Guido van Rossum added the comment:
All in all, Decimal is the odd man out -- it may never become a full
member of the Real ABC. The built-in types complex, float and int (and
long in 2.x) all support mixed-mode arithmetic, and this is one of the
assumptions of the numeric tower -- and of course
Raymond Hettinger added the comment:
Would it be reasonable then to not have any of the numeric tower stuff
put in the decimal module -- basically leave it alone (no __ceil__,
etc)?
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1682
Jeffrey Yasskin added the comment:
Thanks again for the excellent comments.
__init__: good catch.
repr(Rational): The rule for repr is eval(repr(object)) == object.
Unfortunately, that doesn't decide between the two formats, since both
assume some particular import statements. I picked the one
Mark Dickinson added the comment:
Some random comments: take with a large pinch of salt
(1) In __init__ I think you want something like:
self._numerator = int(numerator)//g
instead of
self._numerator = int(numerator / g)
and similarly for the denominator. At the moment I get, for
Mark Dickinson added the comment:
Two more questions:
(1) should a Rational instance be hashable?
(2) Should Rational(5,2) == Decimal('2.5') evaluate to True or False?
If Rationals are hashable and 2.5 == Rational(5, 2) == Decimal('2.5') then the
rule that objects that compare equal should
Changes by Guido van Rossum:
--
assignee: - gvanrossum
nosy: +gvanrossum
priority: - normal
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1682
__
___
57 matches
Mail list logo
