[issue1682] Move Demo/classes/Rat.py to Lib/fractions.py and fix it up.
Changes by Wolfgang Maier wolfgang.ma...@biologie.uni-freiburg.de: -- nosy: +wolma ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1682 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1682] Move Demo/classes/Rat.py to Lib/fractions.py and fix it up.
Mark Dickinson [EMAIL PROTECTED] added the comment: Well, I can't find anything more to fuss about here. :-) Reclosing. -- status: open - closed ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1682 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1682] Move Demo/classes/Rat.py to Lib/fractions.py and fix it up.
Mark Dickinson [EMAIL PROTECTED] added the comment: I agree that if the type of the 2nd arg isn't int or long it should be rejected. That should not slow down the common path (two ints). I'm having second thoughts about this; it doesn't seem worth adding an extra check that has to be applied every time a Fraction is created from a string (or another Rational instance). The condition being checked for (a denominator equal to 1, but not of type int or long) is unlikely to occur in practice, and fairly harmless even if it does occur. So I'm thinking that PBP says leave it alone. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1682 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1682] Move Demo/classes/Rat.py to Lib/fractions.py and fix it up.
Guido van Rossum [EMAIL PROTECTED] added the comment: That's fine. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1682 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1682] Move Demo/classes/Rat.py to Lib/fractions.py and fix it up.
Mark Dickinson [EMAIL PROTECTED] added the comment:
Trailing 'L's removed in r64557.
A couple more minor issues:
(1) fractions.gcd is exported but not documented. I'll add some
documentation for it, unless anyone feels that it shouldn't have been
exported in the first place. If so, please speak up!
(2) The Fraction constructor is a little more lenient than it ought to
be. For example:
Fraction('1.23', 1)
Fraction(123, 100)
I think this should really be a TypeError: a second argument to the
constructor should only be permitted when the first argument is an
integer. However, it seems fairly harmless, so I'm inclined to just
leave this as it is and not mess with it.
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1682
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1682] Move Demo/classes/Rat.py to Lib/fractions.py and fix it up.
Mark Dickinson [EMAIL PROTECTED] added the comment:
Hmm. I don't much like this, though:
Fraction('1.23', 1.0)
Fraction(123, 100)
Fraction('1.23', 1+0j)
Fraction(123, 100)
I'd say these should definitely be TypeErrors.
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1682
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1682] Move Demo/classes/Rat.py to Lib/fractions.py and fix it up.
Guido van Rossum [EMAIL PROTECTED] added the comment:
I think it's okay to accept Fraction('1.23', 1) -- if only because
rejecting it means changing the default for the 2nd arg to None and that
would slow it down again.
I agree that if the type of the 2nd arg isn't int or long it should be
rejected. That should not slow down the common path (two ints).
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1682
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1682] Move Demo/classes/Rat.py to Lib/fractions.py and fix it up.
Mark Dickinson [EMAIL PROTECTED] added the comment: I agree that if the type of the 2nd arg isn't int or long it should be rejected. That should not slow down the common path (two ints). Sounds good. Some care might be needed to avoid invalidating Fraction(n, d) where n and d are instances of numbers.Integral but not of type int or long. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1682 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1682] Move Demo/classes/Rat.py to Lib/fractions.py and fix it up.
Mark Dickinson [EMAIL PROTECTED] added the comment:
I'm reopening this to propose a last-minute minor change:
Can we remove the trailing 'L' from the numerator and denominator in
the repr of a Fraction instance? E.g.,
x = Fraction('9.876543210')
x
Fraction(987654321L, 1L)
x * (1/x)
Fraction(1L, 1L)
I'd rather see Fraction(987654321, 1) and Fraction(1, 1). Does
the 'L' serve any useful purpose?
--
status: closed - open
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1682
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1682] Move Demo/classes/Rat.py to Lib/fractions.py and fix it up.
Raymond Hettinger [EMAIL PROTECTED] added the comment: +1 on removing the L. Also, it would be nice if reduced fractions were restored to ints after the gcd step: Fraction(1*10**18, 3*10**18) Fraction(1L, 3L) ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1682 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1682] Move Demo/classes/Rat.py to Lib/fractions.py and fix it up.
Guido van Rossum [EMAIL PROTECTED] added the comment: +1 on removing the trailing L from the repr. +0 on trying to reduce the values to ints; that would be dead-end code since in 3.0 it's a non-issue. And it doesn't solve the problem with repr. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1682 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1682] Move Demo/classes/Rat.py to Lib/fractions.py and fix it up.
Jeffrey Yasskin added the comment: I agree that we're basically done here. I'm back to -1 on inlining the common case for arithmetic (attached here anyway). Simple cases are already pretty fast, and bigger fractions are dominated by gcd time, not function call overhead. Since duplicating the definitions of arithmetic will make it harder to do tricky things that shrink the arguments to gcd(), we shouldn't do it. I was always +0 to __format__, so not doing it is fine with me. Thanks for everyone's help! -- resolution: - fixed status: open - closed Added file: http://bugs.python.org/file9570/fraction_inline_arith.patch __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1682 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1682] Move Demo/classes/Rat.py to Lib/fractions.py and fix it up.
Mark Dickinson added the comment: I'm wondering what there is left to do here. Are we close to being able to close this issue? Some thoughts: (1) I think the docs could use a little work (just expanding, and giving a few examples). But it doesn't seem urgent that this gets done before the next round of alphas. (2) Looking at it, I'm really not sure that implementing Rational.__format__ is worthwhile; it's not obvious that we need a way to format a Rational as a float. So I'm -0 on this. If others think Rational should have a __format__ method I'm still happy to implement it. Is there much else that needs to be done here? __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1682 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1682] Move Demo/classes/Rat.py to Lib/fractions.py and fix it up.
Mark Dickinson added the comment:
Okay. I'll stop now :)
So I lied. In a spirit of enquiry, I implemented math.gcd, and wrote a
script (lehmer_gcd.py, attached) to produce some relative timings. Here
are the results, on my MacBook Pro (OS X 10.5):
An explanation of the table: I'm computing gcd(a, b) for randomly
chosen a and b with a_digits and b_digits decimal digits, respectively.
The times in the 5th and 6th columns are in seconds; the last column
gives the factor by which math.gcd is faster than the direct Euclidean
Python implementation.
Even for quite small a and b, math.gcd(a, b) is around 10 times faster
than its Python counterpart. For large, roughly equal-sized, a and b,
the C version runs over 30 times faster.
The smallest difference occurs when the two arguments are very different
sizes; then both versions of gcd essentially do one time-consuming
divmod, followed by a handful of tiny operations, so they take
essentially the same time. For Fraction, the arguments will tend to be
around equal size for many applications: this assumes that the actual
real number represented by the Fraction is within a sensible range, even
when the numerator and denominator have grown huge.
For random a and b, gcd(a, b) tends to be very small. So for the last
few entries in the table, the gcds have been artifically inflated (by
calling gcd(g*a, g*b) for some largish g).
On to the results.
a_digits b_digits g_digits ntrials C_Lehmer Py_Euclid Factor
--- - --
110 10 0.066856 0.240867 3.602780
220 10 0.070256 0.314639 4.478466
440 10 0.075708 0.466596 6.163087
770 10 0.082714 0.681443 8.238537
10 1001 0.022336 0.318501 14.259532
20 2001 0.045209 0.752662 16.648436
50 5001 0.128269 2.167890 16.901128
100 1000 1000 0.028053 0.511769 18.242906
1000 10000 1000 0.709453 18.867336 26.594197
110 100 4.215795 148.597223 35.247736
Lopsided gcds
-
20 1000 100 0.000889 0.007659 8.616953
100 200 100 0.000887 0.007665 8.642473
100030 100 0.000727 0.001387 1.908167
3 10000 100 0.000754 0.001457 1.932027
110 100 0.004689 0.004948 1.055219
110 100 0.004691 0.005038 1.073948
500 4000 100 0.020289 0.388080 19.127665
400 5000 100 0.020271 0.389301 19.204768
Large gcd
-
10 10 10 1000 0.005235 0.043507 8.310880
20 20 20 1000 0.008505 0.095732 11.256167
100 100 100 1000 0.041734 0.812656 19.472284
Added file: http://bugs.python.org/file9485/lehmer_gcd.py
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1682
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1682] Move Demo/classes/Rat.py to Lib/fractions.py and fix it up.
Mark Dickinson added the comment: And here's the diff for math.gcd. It's not production quality---it's just there to show what's possible. Added file: http://bugs.python.org/file9486/lehmer_gcd.patch __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1682 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1682] Move Demo/classes/Rat.py to Lib/fractions.py and fix it up.
Guido van Rossum added the comment: A C reimplementation of gcd probably makes little sense -- for large numbers it is dominated by the cost of the arithmetic, and that will remain the same. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1682 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1682] Move Demo/classes/Rat.py to Lib/fractions.py and fix it up.
Mark Dickinson added the comment: A C reimplementation of gcd probably makes little sense -- for large numbers it is dominated by the cost of the arithmetic, and that will remain the same. That's true for a direct translation of the usual algorithm. But there's a variant due to Lehmer which reduces the number of multi- precision operations, and dramatically reduces the number of full- precision divmod operations---they're mostly replaced by n-limb-by-1- limb multiplications and full-precision additions. I'd expect at least a factor of 2 speedup from using this; possibly more. Of course it's impossible to tell without implementing it. I've attached a Python version; note that: * the operations to find x and y at the start of the outer while loop are simple lookups when written in C * the else branch is taken rarely: usually once at the beginning of any gcd() calculation, and then less than 1 time in 2 on average during the reduction. * all the arithmetic in the inner while loop is done with numbers = 2**15 in absolute value. Mark Added file: http://bugs.python.org/file9463/lehmer_gcd.py __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1682 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1682] Move Demo/classes/Rat.py to Lib/fractions.py and fix it up.
Guido van Rossum added the comment: I think this is definitely premature optimization. :-) In any case, before going any further, you should design a benchmark and defend it. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1682 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1682] Move Demo/classes/Rat.py to Lib/fractions.py and fix it up.
Changes by Mark Dickinson: Removed file: http://bugs.python.org/file9463/lehmer_gcd.py __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1682 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1682] Move Demo/classes/Rat.py to Lib/fractions.py and fix it up.
Jeffrey Yasskin added the comment: 1) No worries. Even without inlining the common case of __add__, etc., Fraction is now faster than Decimal for smallish fractions [sum(Fraction(1, i) for i in range(1, 100))], and for large ones [sum(Fraction(1, i) for i in range(1, 1000))] gcd takes so much of the time that I can't see the effects of any of the optimizations I've made. Since I wasn't thinking of this as a high-performance class, I'm taking that as a sign to stop optimizing, but gcd is definitely the function to tackle if anyone wants to keep going. 2) I haven't been following __format__, but adding it to Rational sounds fine to me. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1682 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1682] Move Demo/classes/Rat.py to Lib/fractions.py and fix it up.
Guido van Rossum added the comment: Yay! And my benchmark went from 70 usec to 15 usec. Not bad! PS. Never use relative speedup numbers based on profiled code -- the profiler skews things tremendously. Not saying you did, just stating the obvious. :) __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1682 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1682] Move Demo/classes/Rat.py to Lib/fractions.py and fix it up.
Guido van Rossum added the comment: PS. I can shave off nearly 4 usec of the constructor like this: -self = super(Fraction, cls).__new__(cls) +if cls is Fraction: +self = object.__new__(cls) +else: +self = super().__new__(cls) This would seem to give an upper bound for the gain you can make by moving the check for instantiating an abstract class to C. Your call. I also found that F(2,3)+F(5,7) takes about 22 usecs (or 18 using the above hack). Inlining the common case for addition (Fraction+Fraction) made that go down to 14 usec (combined with the above hack): -__add__, __radd__ = _operator_fallbacks(_add, operator.add) +__xadd__, __radd__ = _operator_fallbacks(_add, operator.add) +def __add__(self, other): +if type(other) is Fraction: +na = self._numerator +da = self._denominator +nb = other._numerator +db = other._denominator +return Fraction(na*db + nb*da, da*db) +return self.__xadd__(other) + __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1682 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1682] Move Demo/classes/Rat.py to Lib/fractions.py and fix it up.
Jeffrey Yasskin added the comment: Thanks for writing the __add__ optimization down. I hadn't realized how simple it was. I think both optimizations are worth it. 22% on a rarely used class is worth 24 lines of python, and I think nearly eliminating the overhead of ABCs (which will prevent them from getting a bad performance reputation) is worth some C. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1682 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1682] Move Demo/classes/Rat.py to Lib/fractions.py and fix it up.
Jeffrey Yasskin added the comment:
r60785 speeds the benchmark up from 10.536s to 4.910s (on top of
whatever my __instancecheck__ fix did). Here are the remaining
interesting-looking calls:
ncalls tottime percall cumtime percall filename:lineno(function)
...
10.2070.2074.9994.999 {sum}
161.5870.0003.4190.000 fractions.py:58(__new__)
70.1700.0003.2360.000 fractions.py:295(forward)
80.6410.0002.8810.000 fractions.py:322(_add)
90.2020.0001.5560.000 benchmark.py:3(genexpr)
160.8290.0000.8290.000 fractions.py:17(gcd)
160.4770.0000.7570.000 abc.py:63(__new__)
330.2460.0000.2460.000 abc.py:164(__instancecheck__)
160.2070.0000.2070.000 {method 'get' of
'dictproxy' objects}
1000710.1850.0000.1850.000 {isinstance}
300.1090.0000.1090.000 fractions.py:200(denominator)
240.0730.0000.0730.000 {built-in method __new__
of type object at 0xfeea0}
150.0650.0000.0650.000 fractions.py:196(numerator)
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1682
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1682] Move Demo/classes/Rat.py to Lib/fractions.py and fix it up.
Nick Coghlan added the comment: Thanks for adding the class methods back Mark. On the constructor front, we got a fair payoff in the early Decimal days just by reordering the type checks in the constructor. Other than that, I'd have to dig into the code a bit more to offer any useful suggestions. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1682 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1682] Move Demo/classes/Rat.py to Lib/fractions.py and fix it up.
Mark Dickinson added the comment: BTW I think the next goal should be to reduce the cost of constructing a Fraction out of to plain ints by at least an order of magnitude. I believe this is possible. I certainly hope so! Here's a very simple (and simplistic) benchmark: # start benchmark from fractions import Fraction from cProfile import run def test1(): return sum(Fraction(1, n*n-1) for n in xrange(2, 10)) run(test1()) #end benchmark On my MacBook this reports a total time of 38.072 seconds, with 22.731 of those (i.e. around 60%) being spent in abc.__instancecheck__ and its callees. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1682 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1682] Move Demo/classes/Rat.py to Lib/fractions.py and fix it up.
Mark Dickinson added the comment: limit_denominator implemented in r60752 from_decimal and from_float restored to classmethods in r60754 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1682 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1682] Move Demo/classes/Rat.py to Lib/fractions.py and fix it up.
Guido van Rossum added the comment: Okay, Nick; you've got me convinced. For some reason I wasn't really thinking of these methods as alternative constructors---in this light, your arguments about doing the same as __new__, and about established patterns, make perfect sense. Looking back at the discussion, Jeffrey looked like he was +/-0 on the change, and Guido was answering a slightly different question (about __add__ instead of constructors); I then took his answer out of context to justify the change :( So I'll change this back unless there's further discussion. Sounds good. BTW I think the next goal should be to reduce the cost of constructing a Fraction out of to plain ints by at least an order of magnitude. I believe this is possible. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1682 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1682] Move Demo/classes/Rat.py to Lib/fractions.py and fix it up.
Mark Dickinson added the comment: Okay, Nick; you've got me convinced. For some reason I wasn't really thinking of these methods as alternative constructors---in this light, your arguments about doing the same as __new__, and about established patterns, make perfect sense. Looking back at the discussion, Jeffrey looked like he was +/-0 on the change, and Guido was answering a slightly different question (about __add__ instead of constructors); I then took his answer out of context to justify the change :( So I'll change this back unless there's further discussion. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1682 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1682] Move Demo/classes/Rat.py to Lib/fractions.py and fix it up.
Mark Dickinson added the comment: Nick Coghlan wrote: I mentioned my dislike of the classmethod-staticmethod change on the python-checkins list, but given the lack of response there, I figure I should bring it up here. Yes, I missed it. Apologies. I'll rethink this (and likely-as-not revert it, but I want to get my head around the issues first). One problem I'm having is imagining any real-life examples of subclasses of Rational. An example or two might help inform the discussion. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1682 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1682] Move Demo/classes/Rat.py to Lib/fractions.py and fix it up.
Nick Coghlan added the comment: I mentioned my dislike of the classmethod-staticmethod change on the python-checkins list, but given the lack of response there, I figure I should bring it up here. It is well established that the way to implement an alternate constructor in Python is to write a classmethod. This means the alternate constructor will behave in a way similar to __new__: invocation via a subclass will result in an instance of that subclass rather than of the base type. Now, this does usually mean the parent class is placing certain expectations on the signature of the subclass constructor. However, this is a pretty common Python idiom, and a lot friendlier than coercing the result to the base type. It makes the common case (constructor signature unchanged or at least compatible) simple, while still permitting the rarer case of changing the signature in an incompatible way (by overriding the class methods as well as the __new__ and __init__ methods) If you want to make this more convenient for users that do want to subclass and change the constructor signature, the expected interface can be factored out to a single method, similar to the way it is done for collections.Set and its _from_iterable class method (i.e. if a Set subclass constructor doesn't accept an iterable directly, it can just override _from_iterable to adapt the supplied iterable to the new interface). -- nosy: +ncoghlan __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1682 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1682] Move Demo/classes/Rat.py to Lib/fractions.py and fix it up.
Jeffrey Yasskin added the comment: Re convergents: In the interest of minimality, I don't think from_continued_fraction and to_continued_fraction need to stick around. I think the other thread established pretty conclusively that .convergents() is not a particularly good building block for either nearby-fraction method, so I'd let people who want it implement it themselves. Neal Norwitz suggested and I agree that .trim() isn't descriptive enough, so let's follow Raymond's alternative of .limit_denominator(). Would you like to commit your implementation? __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1682 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1682] Move Demo/classes/Rat.py to Lib/fractions.py and fix it up.
Mark Dickinson added the comment: Name change in r60721. -- title: Move Demo/classes/Rat.py to Lib/rational.py and fix it up. - Move Demo/classes/Rat.py to Lib/fractions.py and fix it up. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1682 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1682] Move Demo/classes/Rat.py to Lib/fractions.py and fix it up.
Mark Dickinson added the comment: I just checked in another very minor change in r60723. The repr of a Fraction now looks like Fraction(1, 2) instead of Fraction(1,2). Let me know if this change is more controversial than I think it is. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1682 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
