[issue4707] round() shows undocumented behaviour

Senthil added the comment: I also think that documentation should be improved for round(number, [ndigits]). The doc/help says, ndigits can be negative, but does not really say what it means to be negative. It can be confusing to anyione. Take the following example: >>> round(26.5,1) 26.5 >>>

[issue4707] round() shows undocumented behaviour

Changes by Raymond Hettinger : -- assignee: rhettinger -> ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http:

[issue4707] round() shows undocumented behaviour

Mark Dickinson added the comment: > [Me] > > which is a little odd. It's the correct result, but I can't see how [Daniel] > Is it correct? No. :-) It should be 0, as you say. > Given that "round(2, 2**31)" throws an OverflowError I think this is wrong, too. It should be 2. It's another cons

[issue4707] round() shows undocumented behaviour

Daniel Diniz added the comment: Mark Dickinson wrote: > I don't think the hang itself should be considered a bug, any more > than the hang from "10**(2**31-1)" is a bug. Well, besides the fact that you can stop "10**(2**31-1)" with Ctrl+C but not round(2, -2**31+1), the round case may special

[issue4707] round() shows undocumented behaviour

Mark Dickinson added the comment: Aha. The special result for round(x, 1-2**31) has nothing to do with this particular patch. It's a consequence of: #define UNDEF_NDIGITS (-0x7fff) /* Unlikely ndigits value */ in bltinmodule.c. The same behaviour results for all types, not just ints.

[issue4707] round() shows undocumented behaviour

Mark Dickinson added the comment: Cause of segfault was doing Py_XDECREF on a pointer that hadn't been initialised to NULL. Here's a fixed patch. I still get the instant result: >>> round(2, -2**31+1) 2 which is a little odd. It's the correct result, but I can't see how it gets there: unde

[issue4707] round() shows undocumented behaviour

Mark Dickinson added the comment: > >>> round(2, -2**31 + 2) # Press Ctrl + C > Segmentation fault > (backtrace below) Thanks, Daniel. It looks like I messed up the refcounting in the error- handling section of the code. I'll fix this. I don't think the hang itself should be considered a bug

[issue4707] round() shows undocumented behaviour

Daniel Diniz added the comment: Hi Mark, I think there's an overflow for ndigits that predates your patch: >>> round(2, -2**31 +1) 2 >>> round(2, -2**31 +2) nan (it looks like these lines above make 2.6 hang :/) Now, I'm getting a segfault in 3.0 when Ctrl + C-ing during a long running round:

[issue4707] round() shows undocumented behaviour

Mark Dickinson added the comment: Updated patch: fix test_builtin. (Rest of the patch unchanged.) Added file: http://bugs.python.org/file12412/round_int_int2.patch ___ Python tracker __

[issue4707] round() shows undocumented behaviour

Martin v. Löwis added the comment: > Martin, that gives some answers like round(51, -2) --> 0 instead of 100. I see. Here is a version that fixes that. def round(n, i): i = 10**(-i) r = n%(2*i) o = i/2 n -= r if r <= o: return n elif r < 3*o: return n+i

[issue4707] round() shows undocumented behaviour

Raymond Hettinger added the comment: Will review the patch later this evening. Thanks for the submission. ___ Python tracker ___ ___ Python-bu

[issue4707] round() shows undocumented behaviour

Raymond Hettinger added the comment: Martin, that gives some answers like round(51, -2) --> 0 instead of 100. -- assignee: -> rhettinger ___ Python tracker ___ _

[issue4707] round() shows undocumented behaviour

Martin v. Löwis added the comment: Correct me if I'm wrong, but I think computing the quotient is not necessary; the remainder is sufficient: def round(n, i): if i >= 0: return n i = 10**(-i) r = n%(2*i) if r < i: return n-r return n-r+2*i __

[issue4707] round() shows undocumented behaviour

Mark Dickinson added the comment: Here's a first attempt at a patch for round(int, int) -> int. -- keywords: +patch Added file: http://bugs.python.org/file12407/round_int_int.patch ___ Python tracker __

[issue4707] round() shows undocumented behaviour

Raymond Hettinger added the comment: IMO, having long.__round__ return a float is a landmine, guaranteed to cause someone problems someday (problems that are hard to find). -- priority: critical -> release blocker ___ Python tracker

[issue4707] round() shows undocumented behaviour

Martin v. Löwis added the comment: > When PEP 3141 says something should be Real, that includes both int and > float as possibilities (since Real is a supertype of Integral), so it's > consistent with the PEP for round(int, int) to return an int, and I > agree with Mark that round(25, -1) ought

[issue4707] round() shows undocumented behaviour

Mark Dickinson added the comment: > Is your guess for round(25.0, > -1)==30.0 that 25.0*(1/10.0) is slightly more than 2.5 on some > systems? Yes, something like that. I don't think it's feasible to make round perfectly correct (for floats) in all cases without implementing some amount of mu

[issue4707] round() shows undocumented behaviour

Raymond Hettinger added the comment: The code that hands-off long.__round__ to float.__round__ is a train wreck. The intended result can be computed directly and exactly for all sizes of long. -- nosy: +rhettinger priority: -> critical ___ Python t

[issue4707] round() shows undocumented behaviour

Jeffrey Yasskin added the comment: When PEP 3141 says something should be Real, that includes both int and float as possibilities (since Real is a supertype of Integral), so it's consistent with the PEP for round(int, int) to return an int, and I agree with Mark that round(25, -1) ought to retur

[issue4707] round() shows undocumented behaviour

Christian Taylor added the comment: I'm using Arch Linux (32 bit) with kernel 2.6.25 and glibc 2.8 on a core 2 duo. The described behaviour occurs in a precompiled binary of Python 3.0, but also in versions I've compiled just now, which includes Python 3.0+ (release30-maint:67879) As far as the

[issue4707] round() shows undocumented behaviour

Mark Dickinson added the comment: Jeffrey, any opinion on this? -- nosy: +jyasskin ___ Python tracker ___ ___ Python-bugs-list mailing

[issue4707] round() shows undocumented behaviour

Mark Dickinson added the comment: > Why do you say the return type is incorrect? It should, and does, > return a float. The documentation at: http://docs.python.org/dev/3.0/library/functions.html#round says, of round(x[, n]): """The return value is an integer if called with one argument, ot

[issue4707] round() shows undocumented behaviour

Martin v. Löwis added the comment: Why do you say the return type is incorrect? It should, and does, return a float. -- nosy: +loewis ___ Python tracker ___ _

[issue4707] round() shows undocumented behaviour

Mark Dickinson added the comment: Correction: it looks like two bugs to me. I think the wrong-return-type bug is rather serious, possibly a release blocker for 3.0.1. I'll see if I can produce a patch. The incorrect rounding (returning 30.0 instead of 20.0) is less serious, but still needs

[issue4707] round() shows undocumented behaviour

Changes by Giampaolo Rodola' : -- nosy: +giampaolo.rodola ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http:/

[issue4707] round() shows undocumented behaviour

Mark Dickinson added the comment: Looks like a bug to me. I get the expected behaviour on my machine. Python 3.0+ (release30-maint:67878, Dec 20 2008, 17:31:44) [GCC 4.0.1 (Apple Inc. build 5490)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> round(25, -

[issue4707] round() shows undocumented behaviour

New submission from Christian Taylor : I've been playing around with the newly released Python 3.0, and I'm a bit confused about the built-in round()-function. To sum it up in a single example: Python 3.0 (r30:67503, Dec 7 2008, 04:54:04) [GCC 4.3.2] on linux2 >>> round(25, -1) 30.0 I had expe