[issue1780] Decimal constructor accepts newline terminated strings

2008-01-11 Thread Mark Dickinson
Mark Dickinson added the comment: Committed, revision 59929. -- status: open -> closed __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1780> __ ___ P

[issue1682] Move Demo/classes/Rat.py to Lib/rational.py and fix it up.

2008-01-11 Thread Mark Dickinson
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' r

[issue1516613] Decimal should allow leading or trailing spaces.

2008-01-11 Thread Mark Dickinson
Mark Dickinson added the comment: I spoke too soon. This came up again in the discussion for issue #1780 and there was general support for allowing trailing and leading whitespace. Fixed for Python 2.6, revision 59929 -- resolution: -> fixed status: open -> closed supe

[issue1811] True division of integers could be more accurate

2008-01-11 Thread Mark Dickinson
New submission from Mark Dickinson: Division of two longs can produce results that are needlessly inaccurate: >>> from __future__ import division >>> 10**40/10**39 10.002 The correct result is, of course, 10.0, which is exactly representable as a float. The a

[issue1811] True division of integers could be more accurate

2008-01-11 Thread Mark Dickinson
Changes by Mark Dickinson: -- components: +Interpreter Core versions: +Python 2.6, Python 3.0 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1811> __ ___

[issue1811] True division of integers could be more accurate

2008-01-12 Thread Mark Dickinson
Mark Dickinson added the comment: It would be easy and safe to just use a/b = float(a)/float(b) if both a and b are less than 2**53 (assuming IEEE doubles). Then there wouldn't be any loss of speed for small integers. For large integers the algorithm I posted should run in time line

[issue1779] int("- 1") is valud, but float("- 1") isn't. Which is right?

2008-01-12 Thread Mark Dickinson
Mark Dickinson added the comment: For Python 3.0, this is a trivial fix: two lines need to be removed from PyLong_FromString in longobject.c, and then the tests in test_builtin need to be fixed up. (For Python 2.6, the fix would be a bit more involved: PyOS_strtol would also need fixing

[issue1811] True division of integers could be more accurate

2008-01-12 Thread Mark Dickinson
Mark Dickinson added the comment: Tim: is this worth fixing? -- nosy: +tim_one __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1811> __ ___ Python-bugs-

[issue1682] Move Demo/classes/Rat.py to Lib/rational.py and fix it up.

2008-01-13 Thread Mark Dickinson
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.,

[issue1682] Move Demo/classes/Rat.py to Lib/rational.py and fix it up.

2008-01-13 Thread Mark Dickinson
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)

[issue1682] Move Demo/classes/Rat.py to Lib/rational.py and fix it up.

2008-01-15 Thread Mark Dickinson
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://

[issue1811] True division of integers could be more accurate

2008-01-15 Thread Mark Dickinson
Mark Dickinson added the comment: A related problem is that float(n) isn't always correctly rounded for an integer n. A contrived example: >>> n = 2**68 + 2**16 - 1 >>> float(n) 2.9514790517935283e+20 Here the difference between float(n) and the true value of n is a

[issue1859] textwrap doesn't linebreak on "\n"

2008-01-17 Thread Mark Dickinson
Mark Dickinson added the comment: Could you give an example showing the unexpected behaviour, and describing what behaviour you'd expect, please? As far as I can tell, the patch has no effect on textwrap.wrap or textwrap.fill, since any newlines have already been converted to spaces b

[issue1859] textwrap doesn't linebreak on "\n"

2008-01-17 Thread Mark Dickinson
Mark Dickinson added the comment: Is it worth double checking with Greg Ward that this behaviour really is intentional? __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/

[issue1859] textwrap doesn't linebreak on "\n"

2008-01-17 Thread Mark Dickinson
Mark Dickinson added the comment: For what it's worth, I think there is a legitimate complaint here, though it was initially unclear to me exactly what that complaint was. Consider the following: >>> from textwrap import * >>> T = TextWrapper(replace_whitespace=False,

[issue1763] Winpath module - easy access to Windows directories like My Documents

2008-01-17 Thread Mark Hammond
Mark Hammond added the comment: I'm not sure why the approach of "load-em-all" is being taken. Interestingly, SHGetFolderPathW is listed as deprecated, so I doubt that list will grow too much, but the implementation as specified prevents the user from using other facilities av

[issue1694] floating point number round failures under Linux

2008-01-18 Thread Mark Dickinson
Mark Dickinson added the comment: I'm closing this as invalid. -- resolution: -> invalid status: open -> closed __ Tracker <[EMAIL PROTECTED]> <http://bugs.

[issue1682] Move Demo/classes/Rat.py to Lib/rational.py and fix it up.

2008-01-18 Thread Mark Dickinson
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 pla

[issue1869] Builtin round function is sometimes inaccurate for floats

2008-01-18 Thread Mark Dickinson
New submission from Mark Dickinson: The documentation for the builtin round(x, n) says: "Values are rounded to the closest multiple of 10 to the power minus n." This isn't always true; for example: Python 2.6a0 (trunk:59634M, Dec 31 2007, 17:27:56) [GCC 4.0.1 (Apple Compu

[issue1682] Move Demo/classes/Rat.py to Lib/rational.py and fix it up.

2008-01-18 Thread Mark Dickinson
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 updat

[issue1023290] proposed struct module format code addition

2008-01-18 Thread Mark Dickinson
Mark Dickinson added the comment: See also issue #923643. -- nosy: +marketdickinson _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1023290> _ ___

[issue923643] long <-> byte-string conversion

2008-01-18 Thread Mark Dickinson
Mark Dickinson added the comment: It seems to me that this issue is almost entirely subsumed by issue #1023290. I'm quite tempted to close this and direct further discussion there---personally, I'd support Josiah's proposed struct addition. Paul: if you're still list

[issue705836] struct.pack of floats in non-native endian order

2008-01-19 Thread Mark Dickinson
Mark Dickinson added the comment: It's a little odd: the relevant code is in floatobject.c, in _PyFloat_Pack4. The issue is what happens when a Python float (stored internally as a platform double) is packed as an IEEE-754 single-precision float. The current code doesn'

[issue705836] struct.pack of floats in non-native endian order

2008-01-19 Thread Mark Dickinson
Mark Dickinson added the comment: Aha: the C99 standard, section 6.3.1.5, says: When a double is demoted to float, a long double is demoted to double or float, or a value being represented in greater precision and range than required by its semantic type (see 6.3.1.8) is explicitly converted

[issue1640] Enhancements for mathmodule

2008-01-19 Thread Mark Dickinson
Mark Dickinson added the comment: George: I'm certainly still interested in having asinh, acosh and atanh in math---I'm not sure about anyone else, but I consider these three functions to be basic ingredients in any math library. They even appear in most calculus texts. And th

[issue705836] struct.pack of floats in non-native endian order

2008-01-19 Thread Mark Dickinson
Mark Dickinson added the comment: Here's a patch that fixes the test that Collin mentioned to reflect what's actually been happening for the last nearly 5 years, and changes _PyFloat_Pack4 and _PyFloat_Pack8, as follows. When packing a float that's too large for the destinat

[issue1640] Enhancements for mathmodule

2008-01-20 Thread Mark Dickinson
Mark Dickinson added the comment: Excellent! I'll take a look. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1640> __ ___ Python-bugs-list mailing list U

[issue1640] Enhancements for mathmodule

2008-01-20 Thread Mark Dickinson
Mark Dickinson added the comment: One question: is there a policy on what should happen for singularities and domain errors? If not, I think it would be useful to have one. Following the policy may not be achievable on all platforms, but it should be easy to do on major platforms, and at

[issue1640] Enhancements for mathmodule

2008-01-20 Thread Mark Dickinson
Mark Dickinson added the comment: whoops. OverflowError should be something else in the previous post; of course, OverflowError is inappropriate for domain errors (but entirely appropriate for something like exp(1000)). Currently, on Linux I get: - overflow (exp(1000

[issue1640] Enhancements for mathmodule

2008-01-20 Thread Mark Dickinson
Mark Dickinson added the comment: Okay: for now, I guess we just follow the pattern that already exists on Linux and Windows. I think the OS X sqrt(-1) behaviour is a bug. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/

[issue1640] Enhancements for mathmodule

2008-01-20 Thread Mark Dickinson
Mark Dickinson added the comment: No: IEEE-754r and the C99 standard both say clearly that atanh(1) should be infinity and atanh(-1) should be -infinity, and furthermore that the 'divide-by-zero' exception should be raised rather than the 'invalid' exception. It's

[issue1640] Enhancements for mathmodule

2008-01-20 Thread Mark Dickinson
Mark Dickinson added the comment: George: I think my last post was a bit rude. I apologize if it came across that way. Mathematical rigor and IEEE-754 recommendations aren't necessarily in conflict here, though. For example, the natural log function from (0, infinity) to (-inf

[issue1879] sqrt(-1) doesn't raise ValueError on OS X

2008-01-20 Thread Mark Dickinson
New submission from Mark Dickinson: On OS X 10.4, and probably other versions of OS X too, calls to math.log and math.sqrt that should raise ValueError instead return a NaN: Python 2.6a0 (trunk:60144, Jan 20 2008, 21:43:56) [GCC 4.0.1 (Apple Computer, Inc. build 5370)] on darwin Type "

[issue1640] Enhancements for mathmodule

2008-01-20 Thread Mark Dickinson
Mark Dickinson added the comment: Thanks, Tim! Dare I suggest extending these rules to encompass things like sqrt(NaN), log(inf), etc., as follows: - return a special value in Python where IEEE-754r/C99 specifies a special value, but doesn't raise any of the three divide-by-zero, in

[issue1880] Generalize math.hypot function

2008-01-20 Thread Mark Dickinson
Mark Dickinson added the comment: I'm not sure either that such a generalization would belong in math (which right now does little more than expose some basic functions from the C library) or that it should be called hypot. It seems to me that this would belong with other vector-type

[issue1640] Enhancements for mathmodule

2008-01-21 Thread Mark Dickinson
Mark Dickinson added the comment: Christian: I'm definitely not proposing atanh(1) = inf: it should raise ValueError. I'm proposing that we follow Tim's rules for now; this means no change for finite inputs. The new thing here is that since you've made inf and nan

[issue1640] Enhancements for mathmodule

2008-01-21 Thread Mark Dickinson
Mark Dickinson added the comment: Christian: would it be possible for you to tell me what the argument of the log1p call is on Windows in that last branch of c_atanh, for the testcase atanh0022. On OS X I get: Input to log1p is 3.2451855365842669075e+32 It's hard to imagine that th

[issue1640] Enhancements for mathmodule

2008-01-21 Thread Mark Dickinson
Mark Dickinson added the comment: Okay: here's an attempted guess at what's happening on Windows: Near the end of c_atanh, there's a line that reads: r.real = log1p(4.*z.real/((1-z.real)*(1-z.real) + ay*ay))/4.; Somehow, when z.real is 0.99989 and ay is 0, the ar

[issue1640] Enhancements for mathmodule

2008-01-21 Thread Mark Dickinson
Mark Dickinson added the comment: Sorry: those lines should have been: double temp = 1-z.real; printf("temp is %.19e\n", temp); r.real = log1p(4.*z.real/(temp*temp + ay*ay))/4.; __ Tracker <[EMAIL PROTECTED]> <http://bugs.p

[issue1153226] string interpolation breaks with %d and large float

2008-01-21 Thread Mark Dickinson
Mark Dickinson added the comment: This is a duplicate of issue #1742669 -- nosy: +marketdickinson resolution: -> duplicate status: open -> closed superseder: -> "%d" format handling for long values _ Tracker <[E

[issue1640] Enhancements for mathmodule

2008-01-21 Thread Mark Dickinson
Mark Dickinson added the comment: Sorry: I should have read more carefully. So math.atanh works on Linux but is producing some strange results on Windows. It's still rather puzzling though. I still suspect that it's the argument to log1p that's coming out wrong rather

[issue1640] Enhancements for mathmodule

2008-01-21 Thread Mark Dickinson
Mark Dickinson added the comment: The problem with atanh is that it should be using absx throughout, rather than x. So in "if (absx < 0.5)" branch and the following branch, replace all occurrences of x with absx, and it should work. One other comment: asinh shouldn't dire

[issue1640] Enhancements for mathmodule

2008-01-21 Thread Mark Dickinson
Mark Dickinson added the comment: Also, for the C-level routines, atanh(1.0) and atanh(-1.0) should definitely return infinity and -infinity (and probably set errno as well.) Note that this is not an argument about what Python should do: Python will still raise a ValueError for atanh(1.0

[issue1640] Enhancements for mathmodule

2008-01-21 Thread Mark Dickinson
Mark Dickinson added the comment: One more comment: the Py_IS_NAN test in acosh is likely never reached, since the comparison x >= two_pow_p28 will probably evaluate to 0 when x is a NaN. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.o

[issue1640] Enhancements for mathmodule

2008-01-21 Thread Mark Dickinson
Mark Dickinson added the comment: Also: -1.0 shouldn't be returned at this level to indicate an error; these are pure C functions we're writing---the Python wrappers, and Python error conventions, apply further up the chain somewhere. Just so I'm doing something a little mo

[issue1678380] 0.0 and -0.0 identified, with surprising results

2008-01-21 Thread Mark Dickinson
Mark Dickinson added the comment: This was fixed in the trunk in revision 57284. I've backported the fix to Python 2.5.2 in revision 60183. Leaving this open because there's still a problem for complex numbers, though I guess this is less likely to bite people: Python 2.6a0 (tr

[issue1678380] 0.0 and -0.0 identified, with surprising results

2008-01-21 Thread Mark Dickinson
Mark Dickinson added the comment: Here's a patch, against the trunk, that imitates Alex's fix for the complex case. -- keywords: +patch Added file: http://bugs.python.org/file9255/plus_minus_0j.patch _ Tracker <[EMAIL PROT

[issue1678668] fix a bug mixing up 0.0 and-0.0

2008-01-21 Thread Mark Dickinson
Mark Dickinson added the comment: This can be closed, I think: it's already been fixed in the trunk (with a different fix, also due to Alex, from the one given here) and the fix has been backported to 2.5.2. Not sure what the appropriate resolution is here; plumping for 'o

[issue1640] Enhancements for mathmodule

2008-01-21 Thread Mark Dickinson
Mark Dickinson added the comment: Hmmm. For atanh(1): raising OverflowError is actually consistent with what currently happens. The only singularity that's already present in math is log(0), and it seems that that raises OverflowError on OS X, Linux and Windows... I wonder whether

[issue1920] while else loop seems to behave incorrectly

2008-01-24 Thread Mark Summerfield
New submission from Mark Summerfield: I am using: Python 3.0a2 (r30a2:59382, Dec 17 2007, 08:47:22) [GCC 4.1.2 20070626 (Red Hat 4.1.2-13)] on linux2 IDLE 3.0a1 This seems wrong: >>> while False: print("no") else: print("yes") >

[issue1920] while else loop seems to behave incorrectly

2008-01-24 Thread Mark Dickinson
Mark Dickinson added the comment: This bug is also present in the trunk, with while 0 instead of while False. This appears closely related to issue #1875. In my opinion this is a serious bug in the core language. I'm not sure whether it's serious enough to be considered a shows

[issue1875] "if 0: return" not raising SyntaxError

2008-01-24 Thread Mark Dickinson
Mark Dickinson added the comment: See also issue #1920 -- nosy: +marketdickinson __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1875> __ ___ Python-bugs-

[issue1920] while else loop seems to behave incorrectly

2008-01-24 Thread Mark Dickinson
Mark Dickinson added the comment: Looks like Amaury found his svn access. Is it okay to close this now? -- resolution: -> accepted status: open -> closed __ Tracker <[EMAIL PROTECTED]> <http://bugs.pytho

[issue1920] while else loop seems to behave incorrectly

2008-01-24 Thread Mark Dickinson
Mark Dickinson added the comment: Forgot to say: Amaury checked his fix in in revision #60265 (trunk) and revision #60268 (Python 2.5). Thanks for the bug report, Mark! __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/

[issue1933] os.path.isabs documentation error

2008-01-25 Thread Mark Dickinson
Changes by Mark Dickinson: -- resolution: -> duplicate status: open -> closed __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1933> __ ___ Python

[issue1682] Move Demo/classes/Rat.py to Lib/rational.py and fix it up.

2008-01-27 Thread Mark Dickinson
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 flo

[issue923643] long <-> byte-string conversion

2008-01-28 Thread Mark Dickinson
Mark Dickinson added the comment: Closing this due to little-or-no activity for over three years. Antoine's use case seems to me to be covered by issue #1023290. Trevor, please speak up if you want to keep this alive. -- resolution: -> rejected status: open -> pending

[issue1905] PythonLauncher not working correctly on OS X 10.5/Leopad

2008-01-30 Thread Mark Dickinson
Mark Dickinson added the comment: I can reproduce this in the trunk, on OS X 10.5.1/Intel: after a ./configure --enable-framework && make && sudo make altinstall ctrl-clicking on a simple python file on the Desktop and selecting OpenWith -> PythonLauncher fails to run th

[issue1979] Make Decimal comparisons with NaN less arbitrary

2008-01-30 Thread Mark Dickinson
New submission from Mark Dickinson: For Python 3.0 the decimal module got rich comparisons. Those comparisons have somewhat unconventional behavior with respect to NaNs, as seen below: <, <= and == comparisons involving NaNs always return False, while >, >= and != comparisons a

[issue1979] Make Decimal comparisons with NaN less arbitrary

2008-01-31 Thread Mark Dickinson
Mark Dickinson added the comment: Yes, I think it's necessary. Speaking of standards, it's the current behavior which isn't backed by any standard or rationale other than the historical one involving now-defunct 3- way comparisons. The proposed behavior is much closer to that s

[issue1979] Make Decimal comparisons with NaN less arbitrary

2008-01-31 Thread Mark Dickinson
Mark Dickinson added the comment: Here's a patch (richcmp_signal.patch) that gives an alternative way of doing things: all <, <=, > and >= comparisons involving a NaN raise the InvalidOperation flag (using exactly the same semantics as those specified for compar

[issue1678380] 0.0 and -0.0 identified, with surprising results

2008-01-31 Thread Mark Dickinson
Mark Dickinson added the comment: Bug identifying 0j and -0j fixed for Python 2.6 in revision 60483. Martin, can this be backported to 2.5.2? I'll assume not, unless I hear otherwise from you. -- status: open -> pending _ Tracker <[EMAI

[issue1514428] NaN comparison in Decimal broken

2008-02-01 Thread Mark Dickinson
Mark Dickinson added the comment: See issue #1979 for a possible fix. _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1514428> _ ___ Python-bugs-list

[issue1682] Move Demo/classes/Rat.py to Lib/rational.py and fix it up.

2008-02-02 Thread Mark Dickinson
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

[issue1682] Move Demo/classes/Rat.py to Lib/rational.py and fix it up.

2008-02-02 Thread Mark Dickinson
Mark Dickinson added the comment: Regex changed in r60530. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1682> __ ___ Python-bugs-list mailing list Unsubs

[issue2000] Undefined symbols: _PyOS_mystrnicmp on Mac OS X

2008-02-02 Thread Mark Dickinson
Mark Dickinson added the comment: I assume this is on OS X 10.4? I can't reproduce the failure on Leopard. -- nosy: +marketdickinson __ Tracker <[EMAIL PROTECTED]> <http://bugs.python

[issue705836] struct.pack of floats in non-native endian order

2008-02-05 Thread Mark Dickinson
Mark Dickinson added the comment: I'm stealing this issue from Tim, and downgrading the priority to normal (it was the original bug that was high priority). -- assignee: tim_one -> marketdickinson priority: high -> normal versions: +Python 2.6,

[issue1979] Make Decimal comparisons with NaN less arbitrary

2008-02-06 Thread Mark Dickinson
Mark Dickinson added the comment: Okay: I checked in this change in r60630. The checkin includes comments in the code and an extra paragraph describing this behavior in the documentation. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/

[issue1514428] NaN comparison in Decimal broken

2008-02-06 Thread Mark Dickinson
Mark Dickinson added the comment: Fixed for Python 2.6 in r60630. -- resolution: -> fixed status: open -> closed _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.o

[issue2041] __getslice__ still called

2008-02-07 Thread Mark Dickinson
Mark Dickinson added the comment: I think the docs do a good job of explaining this; in particular, they say, in http://docs.python.org/dev/reference/datamodel.html#special-method- names: "However, built-in types in CPython currently still implement __getslice__()." and ex

[issue2041] __getslice__ still called

2008-02-07 Thread Mark Dickinson
Mark Dickinson added the comment: Well, documentation patches are always welcome, I believe :) If you can point to a particular place in the documentation and suggest alternative (or extra) wording that might help, post it here and I'll deal with it. -- resolution: -> invali

[issue1979] Make Decimal comparisons with NaN less arbitrary

2008-02-07 Thread Mark Dickinson
Mark Dickinson added the comment: Closing. -- resolution: -> fixed status: open -> closed __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1979> __ _

[issue1682] Move Demo/classes/Rat.py to Lib/rational.py and fix it up.

2008-02-07 Thread Mark Dickinson
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

[issue1682] Move Demo/classes/Rat.py to Lib/rational.py and fix it up.

2008-02-09 Thread Mark Dickinson
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_c

[issue1682] Move Demo/classes/Rat.py to Lib/rational.py and fix it up.

2008-02-10 Thread Mark Dickinson
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

[issue1682] Move Demo/classes/Rat.py to Lib/rational.py and fix it up.

2008-02-10 Thread Mark Dickinson
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

[issue1682] Move Demo/classes/Rat.py to Lib/rational.py and fix it up.

2008-02-10 Thread Mark Dickinson
Mark Dickinson added the comment: Fair enough. Should it be fractions.Fraction or fraction.Fraction? __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1682> __ ___

[issue1682] Move Demo/classes/Rat.py to Lib/rational.py and fix it up.

2008-02-10 Thread Mark Dickinson
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 Lib

[issue1682] Move Demo/classes/Rat.py to Lib/fractions.py and fix it up.

2008-02-10 Thread Mark Dickinson
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.o

[issue1682] Move Demo/classes/Rat.py to Lib/fractions.py and fix it up.

2008-02-10 Thread Mark Dickinson
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 <[EM

[issue1481296] long(float('nan'))!=0L

2008-02-11 Thread Mark Dickinson
Mark Dickinson added the comment: A late comment: I agree with Ronald here; mightn't it make more sense to raise an exception (ValueError?) for long(float("nan"))? For comparison, long(float("inf")) currently raises OverflowError, at least on OS X.

[issue1682] Move Demo/classes/Rat.py to Lib/fractions.py and fix it up.

2008-02-12 Thread Mark Dickinson
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: # s

[issue1682] Move Demo/classes/Rat.py to Lib/fractions.py and fix it up.

2008-02-12 Thread Mark Dickinson
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] Move Demo/classes/Rat.py to Lib/fractions.py and fix it up.

2008-02-12 Thread Mark Dickinson
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. Looki

[issue1682] Move Demo/classes/Rat.py to Lib/fractions.py and fix it up.

2008-02-12 Thread Mark Dickinson
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 (

[issue2103] __x should be _x in documentation of property()

2008-02-13 Thread Mark Dickinson
Mark Dickinson added the comment: Thanks for the report! It looks like this was previously reported in issue #1575746, and has been fixed in the 2.5 maintenance branch and the trunk. Python 2.5.2 should be out any day now; the fix should then hit docs.python.org. -- nosy

[issue1678380] 0.0 and -0.0 identified, with surprising results

2008-02-13 Thread Mark Dickinson
Mark Dickinson added the comment: Closing. -- status: pending -> closed _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1678380> _ ___ Python-bu

[issue2103] __x should be _x in documentation of property()

2008-02-13 Thread Mark Dickinson
Mark Dickinson added the comment: I'm guessing that you used the 'search in open issues' box at the top right. Of course, the problem is that this issue was already closed. Instead, go to 'Search' on the left-hand side under 'Issues', enter 'pro

[issue2103] __x should be _x in documentation of property()

2008-02-13 Thread Mark Dickinson
Mark Dickinson added the comment: I should have added: You can also check the in-development version of the documentation at docs.python.org/dev to see if it's already been fixed. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python

[issue2114] test_decimal failure on OSX 10.3

2008-02-14 Thread Mark Dickinson
Mark Dickinson added the comment: It looks like you've got a stale normalize.decTest file in Lib/test/decimaltestdata. This file shouldn't be present. Can you do a fresh svn checkout and see if the problem persists? -- nosy: +marke

[issue2114] test_decimal failure on OSX 10.3

2008-02-14 Thread Mark Dickinson
Mark Dickinson added the comment: Hmm. But others may run into this problem as well. Is there any way to force the upgrade install to remove this file? __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/

[issue2114] test_decimal failure on OSX 10.3

2008-02-14 Thread Mark Dickinson
Mark Dickinson added the comment: A cheap and easy fix would be to update normalize.decTest so that's it's an exact copy of reduce.decTest. This would result in all the normalization tests being run twice, but that's probably better than seeing failing tests. (What happened he

[issue2110] Implement __format__ for Decimal

2008-02-14 Thread Mark Dickinson
Mark Dickinson added the comment: I can take a look at this if you like. But I don't want to spoil your fun :) -- nosy: +marketdickinson __ Tracker <[EMAIL PROTECTED]> <http://bugs.python

[issue2138] Factorial

2008-02-18 Thread Mark Dickinson
Mark Dickinson added the comment: I don't think it would be appropriate to add this as a method of int; it seems like unnecessary clutter on a core type. Perhaps a math.factorial function could be considered? Historically, the math module has just been a way to wrap the (mostly floating-

[issue2138] Factorial

2008-02-18 Thread Mark Dickinson
Mark Dickinson added the comment: > Yeah, it's a one-liner, but so is hypot Except that hypot is not a one-liner, if you want to get edge cases right. (Consider hypot(1e200, 1e200), or hypot(1e-200, 1e-200).) __ Tracker <[EMAIL PROTEC

[issue2138] Factorial

2008-02-18 Thread Mark Dickinson
Mark Dickinson added the comment: > Should there be some upper limit on the argument math.factorial would take? I'd say not. Any such limit would be artificial, and an arbitrary choice. Just let the natural time and space requirements be the limitin

[issue1600] str.format() produces different output on different platforms (Py30a2)

2008-02-18 Thread Mark Dickinson
Mark Dickinson added the comment: I know I'm coming a bit late to this discussion, but I wanted to point out that the C99 standard does actually specify how many digits should be in the exponent of a "%e"-formatted number: In section 7.19.6, in the documentation for fprintf,

[issue1682] Move Demo/classes/Rat.py to Lib/fractions.py and fix it up.

2008-02-18 Thread Mark Dickinson
Mark Dickinson added the comment: Two things: (1) Speedup. I haven't been helping much here; apologies. Christian suggested that a C implementation of gcd might help. Is this true, or are we not yet at the stage where the gcd calls are significant? There are some basic tricks tha

[issue2138] Factorial

2008-02-18 Thread Mark Dickinson
Mark Dickinson added the comment: > Since the domain and range are ints/longs, this makes more sense as a > method on than as a math module function. Fair enough. Raymond, do you have any thoughts on where a gcd implementation might most usefully live? Should it stay in fractions.

[issue2138] Factorial

2008-02-18 Thread Mark Dickinson
Mark Dickinson added the comment: The other issue here is that I see factorial as being the thin end of the wedge. If factorial were implemented, it would probably only be on the order of minutes before people wanted to know where the binomial() function was. So it seems to me that either

<    18   19   20   21   22   23   24   25   26   27   >