Re: [Python-Dev] Return type of round, floor, and ceil in 2.6
On Jan 5, 2008 4:20 PM, Tim Peters [EMAIL PROTECTED] wrote: [Guido] Wow. Do you have an opinion as to whether we should adopt round-to-even at all (as a default)? Yes: yes :-) Thanks for the suggestion, Tim. Here's a new proposed patch to the pep. It still allows type-defined half-rounding behavior so that Decimal can follow the current context. I'll submit it tomorrow unless there are significant objections. Index: pep-3141.txt === --- pep-3141.txt(revision 59739) +++ pep-3141.txt(working copy) @@ -205,8 +205,12 @@ def __round__(self, ndigits:Integral=None): Rounds self to ndigits decimal places, defaulting to 0. -If ndigits is omitted or None, returns an Integral, otherwise -returns a Real. Rounds half toward even. +If ndigits is omitted or None, returns an Integral, +otherwise returns a Real, preferably of the same type as +self. Types may choose which direction to round half. For +example, float rounds half toward even, and Decimal rounds +it according to the current context. + raise NotImplementedError @@ -428,10 +432,14 @@ least Integral ``= x``. 4. ``__round__(self)``, called from ``round(x)``, which returns the - Integral closest to ``x``, rounding half toward even. There is also - a 2-argument version, ``__round__(self, other)``, called from - ``round(x, y)``, which should return a Real. + Integral closest to ``x``, rounding half as the type chooses. + ``float`` will change in 3.0 to round half toward even. There is + also a 2-argument version, ``__round__(self, ndigits)``, called + from ``round(x, ndigits)``, which should return a Real. +In 2.6, ``math.floor``, ``math.ceil``, and ``round`` will continue to +return floats. + Because the ``int()`` conversion implemented by ``float`` (and by ``decimal.Decimal``) is equivalent to but less explicit than ``trunc()``, let's remove it. (Or, if that breaks too much, just add a -- Namasté, Jeffrey Yasskin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Return type of round, floor, and ceil in 2.6
On Jan 4, 2008 8:50 AM, Guido van Rossum [EMAIL PROTECTED] wrote:
On Jan 4, 2008 12:13 AM, Jeffrey Yasskin [EMAIL PROTECTED] wrote:
On Jan 3, 2008 10:37 AM, Guido van Rossum [EMAIL PROTECTED] wrote:
Well, as issue 1689 states, the backporting was commited by Jeffrey on
rev 5967 [2], so this is the time to understand if we want this or
not.
This is a problem. Right now, in the trunk, math.float(1) returns 1,
where it should return 1.0 for compatibility with 2.5. Jeffrey, can
you fix this and similar incompatibilities you introduced?
Whoops! I've committed r59707 to fix math.{floor,ceil}. Let me know if
you find any other problems. ... Hmm. I've also changed the behavior
of round(2.5). I'll change that back tomorrow morning.
Looks like in Python 2.6, round(0.5) right now returns 0.0, whereas in
2.5, it returns 1.0.
I think it should return 1.0, for best compatibility with Python 2.5.
I haven't seen any answers to the original question. It looks like
Decimal is decided by 2.5 too: return a float from everything.
Right.
Rational, being a completely new type, is up to you guys, but because
new support for the conversion routines seems to be rare, it's
probably best to have it return floats too.
I think the pre-3.0 rule should be: round(), math.floor(), math.ceil()
*always* return a float.
These rollbacks, and that of pow(-1,.5)==1j are submitted as r59731.
Keep letting me know what else I broke.
--
Namasté,
Jeffrey Yasskin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Return type of round, floor, and ceil in 2.6
On Jan 4, 2008 10:16 PM, [EMAIL PROTECTED] wrote: On 4 Jan, 10:45 pm, [EMAIL PROTECTED] wrote: [GvR to Tim] Do you have an opinion as to whether we should adopt round-to-even at all (as a default)? For the sake of other implementations (Jython, etc) and for ease of reproducing the results with other tools (Excel, etc), the simplest choice is int(x+0.5). That works everywhere, it is easy to explain, it runs fast, and it is not hard to get right. I agree for the default. Except the part where Excel, Jython, and Python's current round, actually use sign(x) * int(abs(x)+0.5), so maybe it's not *completely* easy to get right ;-). Having other rounding methods *available*, though, would be neat. The only application I've ever worked on where I cared about the difference, the user had to select it (since accounting requirements differ by jurisdiction and, apparently, by bank preference). Having a standard way to express this (especially if it worked across different numeric types, but perhaps I digress) would be pleasant. Implementing stochastic rounding and banker's rounding oneself, while not exactly hard, is a drag. The decimal module already supports rounding modes in its context. For other types, perhaps converting to decimal might be good enough? -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Return type of round, floor, and ceil in 2.6
On Jan 5, 2008 12:56 AM, Jeffrey Yasskin [EMAIL PROTECTED] wrote:
On Jan 4, 2008 8:50 AM, Guido van Rossum [EMAIL PROTECTED] wrote:
On Jan 4, 2008 12:13 AM, Jeffrey Yasskin [EMAIL PROTECTED] wrote:
On Jan 3, 2008 10:37 AM, Guido van Rossum [EMAIL PROTECTED] wrote:
Well, as issue 1689 states, the backporting was commited by Jeffrey on
rev 5967 [2], so this is the time to understand if we want this or
not.
This is a problem. Right now, in the trunk, math.float(1) returns 1,
where it should return 1.0 for compatibility with 2.5. Jeffrey, can
you fix this and similar incompatibilities you introduced?
Whoops! I've committed r59707 to fix math.{floor,ceil}. Let me know if
you find any other problems. ... Hmm. I've also changed the behavior
of round(2.5). I'll change that back tomorrow morning.
Looks like in Python 2.6, round(0.5) right now returns 0.0, whereas in
2.5, it returns 1.0.
I think it should return 1.0, for best compatibility with Python 2.5.
I haven't seen any answers to the original question. It looks like
Decimal is decided by 2.5 too: return a float from everything.
Right.
Rational, being a completely new type, is up to you guys, but because
new support for the conversion routines seems to be rare, it's
probably best to have it return floats too.
I think the pre-3.0 rule should be: round(), math.floor(), math.ceil()
*always* return a float.
These rollbacks, and that of pow(-1,.5)==1j are submitted as r59731.
Keep letting me know what else I broke.
I think the consensus is against round-to-even in 3.0 -- this requires
a PEP update as well as code changes. (Sorry for having caused so much
extra work, I should have flagged this earlier.)
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Return type of round, floor, and ceil in 2.6
On Jan 5, 2008 8:56 AM, Guido van Rossum [EMAIL PROTECTED] wrote:
I think the consensus is against round-to-even in 3.0 -- this requires
a PEP update as well as code changes. (Sorry for having caused so much
extra work, I should have flagged this earlier.)
I'm not convinced that speed is a real issue in this case, since this
is only the explicit round() operation and not rounding for arithmetic
operations. But consistency with other languages is important.
Does the following patch to the PEP represent the consensus? If so,
I'll check it in, and update the py3k branch and wikipedia article to
match. I've allowed each type to define its own half-rounding behavior
so that Decimal can follow the current context, and float can, once
there's a portable way to set it (like C99's fesetround), follow the
current rounding mode (if people want that at the time).
Index: pep-3141.txt
===
--- pep-3141.txt(revision 59739)
+++ pep-3141.txt(working copy)
@@ -206,7 +206,10 @@
Rounds self to ndigits decimal places, defaulting to 0.
If ndigits is omitted or None, returns an Integral, otherwise
-returns a Real. Rounds half toward even.
+returns a Real. Types may choose which direction to round half. For
+example, float rounds half away from 0, and Decimal rounds it
+according to the active context.
+
raise NotImplementedError
@@ -428,14 +431,15 @@
least Integral ``= x``.
4. ``__round__(self)``, called from ``round(x)``, which returns the
- Integral closest to ``x``, rounding half toward even. There is also
- a 2-argument version, ``__round__(self, other)``, called from
- ``round(x, y)``, which should return a Real.
+ Integral closest to ``x``, rounding half as the type chooses. There
+ is also a 2-argument version, ``__round__(self, other)``, called
+ from ``round(x, y)``, which should return a Real.
Because the ``int()`` conversion implemented by ``float`` (and by
``decimal.Decimal``) is equivalent to but less explicit than
``trunc()``, let's remove it. (Or, if that breaks too much, just add a
-deprecation warning.)
+deprecation warning.) In 2.6, ``math.floor``, ``math.ceil``, and
+``round`` will continue to return floats.
``complex.__{divmod,mod,floordiv,int,float}__`` also go away. It would
be nice to provide a nice error message to help confused porters, but
--
Namasté,
Jeffrey Yasskin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Return type of round, floor, and ceil in 2.6
On Sat, Jan 05, 2008 at 05:35:45PM -0200, Facundo Batista wrote: 2008/1/5, Art Rasmussen [EMAIL PROTECTED]: Added Python to the referenced article (because I believe Python should be seen everywhere C#, PHP, Visual Basic, etc., are seen). Please let me know if the article needs updating/fixing. Well, don't know. It talks about the rounding in Python, but mentioning only the binary floating point. In Decimal you have a lot of different roundings available... it's worth to mention them? IMO it's worth to mention the existing of them, briefly. Oleg. -- Oleg Broytmannhttp://phd.pp.ru/[EMAIL PROTECTED] Programmers don't die, they just GOSUB without RETURN. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Return type of round, floor, and ceil in 2.6
2008/1/5, Art Rasmussen [EMAIL PROTECTED]: Added Python to the referenced article (because I believe Python should be seen everywhere C#, PHP, Visual Basic, etc., are seen). Please let me know if the article needs updating/fixing. Well, don't know. It talks about the rounding in Python, but mentioning only the binary floating point. In Decimal you have a lot of different roundings available... it's worth to mention them? Regards, -- .Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Return type of round, floor, and ceil in 2.6
On 04:54 pm, [EMAIL PROTECTED] wrote: On Jan 4, 2008 10:16 PM, [EMAIL PROTECTED] wrote: Having other rounding methods *available*, though, would be neat. The only application I've ever worked on where I cared about the difference, the user had to select it (since accounting requirements differ by jurisdiction and, apparently, by bank preference). Having a standard way to express this (especially if it worked across different numeric types, but perhaps I digress) would be pleasant. Implementing stochastic rounding and banker's rounding oneself, while not exactly hard, is a drag. The decimal module already supports rounding modes in its context. For other types, perhaps converting to decimal might be good enough? Yes, that's the right thing to do. I had missed it. After all it is decimal rounding I want, and any financial applications I'm going to write these days are using decimals already for all the usual reasons. At first I didn't realize why I'd missed this feature. While the rounding *modes* are well documented, though, after 20 minutes of reading documentation I still haven't found a method or function that simply rounds a decimal to a given significant digit. Is there one, should there be one, or is the user simply meant to use Context.quantize with appropriate arguments? ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Return type of round, floor, and ceil in 2.6
On Jan 5, 2008 5:54 PM, [EMAIL PROTECTED] wrote: At first I didn't realize why I'd missed this feature. While the rounding *modes* are well documented, though, after 20 minutes of reading documentation I still haven't found a method or function that simply rounds a decimal to a given significant digit. Is there one, should there be one, or is the user simply meant to use Context.quantize with appropriate arguments? quantize is about as close as it gets. Note that it's a Decimal method as well as a Context method, so you can invoke it directly on a given decimal: Decimal(2.34567).quantize(Decimal(0.01)) Decimal(2.35) I've also occasionally felt a need for a simple rounding function that isn't affected by context. Would others be interested in such a function being added to Decimal? I guess there are two possibly useful operations: (1) round to a particular decimal place ( e.g. nearest ten, nearest hundredth, ..) and (2) to round to a particular number of significant digits; in both cases, the user should be able to specify the desired rounding mode. And for each operation, it might also be useful to specify whether the result should be padded with zeros to the desired length or not. (i.e. when rounding 3.399 to 3 significant places, should it produce 3.4 or 3.40?) Any thoughts? Mark ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Return type of round, floor, and ceil in 2.6
[Tim] Because add a half and chop was also in wide use for even longer, is also (Wikipedia notwithstanding) part of many standards (for example, the US IRS requires it if you do your taxes under the round to whole dollars option), and-- probably the real driver --is a little cheaper to implement for normal sized floats. Curiously, round-to-nearest can be unboundedly more expensive to implement in some obscure contexts when floats can have very large exponents (as they can in Python's decimal module -- this is why the proposed decimal standard allows operations like remainder-near to fail if applied to inputs that are too far apart: http://www2.hursley.ibm.com/decimal/daops.html#footnote.8 The secret reason is that it can be unboundedly more expensive to determine the last bit of the quotient (to see whether it's even or odd) than to determine an exact remainder). [Guido] Wow. Do you have an opinion as to whether we should adopt round-to-even at all (as a default)? Yes: yes :-) There's no need to be unduly influenced by some obscure contexts when floats can have very large exponents, and the decimal standard already weasels its way out of the bad consequences then. I should clarify that the standard allows relevant operations to fail then in the same sense the IRS allows you to pay your taxes: it's not just allowed, failure is required. Nearest/even is without doubt the rounding method experts want most often, which is half of what makes it the best default. The other half is that, while newbies don't understand why experts would want it, the underlying reasons nevertheless act to spare newbies from subtle numeric problems. As to what the numerically innocent /expect/, (at least) all of the above is my only guess. For example (and here I'm making up a very simple one to show the essence), under the Windows native Python %.0f % 2.5 produces 3, while under glibc-based implementations (including Cygwin's Python) it produces 2. Over the years I've seen bug reports filed against both outcomes. According to the 754 standard, the glibc-based result (nearest/even rounding) is correct, and the Microsoft result is wrong. Why fight it? All the HW float operations do nearest/even rounding now too (by default), ditto the decimal module, and I'm secretly grateful the people who decided on those were downright eager to oppose Excel's numerically innocent implementors ;-) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Return type of round, floor, and ceil in 2.6
[Mark Dickinson] quantize is about as close as it gets. Note that it's a Decimal method as well as a Context method, so you can invoke it directly on a given decimal: Decimal(2.34567).quantize(Decimal(0.01)) Decimal(2.35) This reads better in many cases if you define a constant first, like: PENNIES = Decimal(0.01) ... [lots of code] ... rounded = some_decimal.quantize(PENNIES) I've also occasionally felt a need for a simple rounding function that isn't affected by context. Would others be interested in such a function being added to Decimal? I guess there are two possibly useful operations: (1) round to a particular decimal place ( e.g. nearest ten, nearest hundredth, ..) and (2) to round to a particular number of significant digits; in both cases, the user should be able to specify the desired rounding mode. And for each operation, it might also be useful to specify whether the result should be padded with zeros to the desired length or not. ( i.e. when rounding 3.399 to 3 significant places, should it produce 3.4 or 3.40?) Any thoughts? +1 from me. Like the 754 standard, the decimal std is trying to mandate a more-or-less minimal set of core functionality, with no concern for user interface. Convenience functions can be valuable additions in such cases, I agree it's far from obvious to most how to accomplish rounding using the decimal facilities. I think it's obvious ;-) that rounding 3.399 to 3 sig. dig. should produce 3.40. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Return type of round, floor, and ceil in 2.6
On Jan 4, 2008 1:31 PM, Tim Peters [EMAIL PROTECTED] wrote: Curiously, round-to-nearest can be unboundedly more expensive to implement in some obscure contexts when floats can have very large exponents (as they can in Python's decimal module -- this is why the proposed decimal standard allows operations like remainder-near to fail if applied to inputs that are too far apart: Just to be clear, this problem doesn't come up in round(), right? Because in round(), you just test the evenness of the last digit computed. There is never a need to compute extra digits just to perform the test. -- Daniel Stutzbach, Ph.D. President, Stutzbach Enterprises LLC ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Return type of round, floor, and ceil in 2.6
On Sat, Jan 05, 2008, [EMAIL PROTECTED] wrote: At first I didn't realize why I'd missed this feature. While the rounding *modes* are well documented, though, after 20 minutes of reading documentation I still haven't found a method or function that simply rounds a decimal to a given significant digit. Is there one, should there be one, or is the user simply meant to use Context.quantize with appropriate arguments? Rephrasing Uncle Timmy: Decimal has so far focused on adhering to the decimal standard, not on providing convenience to users. As long as the core continues to adhere to the standard, there's no reason not to add convenience. -- Aahz ([EMAIL PROTECTED]) * http://www.pythoncraft.com/ Weinberg's Second Law: If builders built buildings the way programmers wrote programs, then the first woodpecker that came along would destroy civilization. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Return type of round, floor, and ceil in 2.6
[Tim] Curiously, round-to-nearest can be unboundedly more expensive to implement in some obscure contexts when floats can have very large exponents (as they can in Python's decimal module -- this is why the proposed decimal standard allows operations like remainder-near to fail if applied to inputs that are too far apart: [Daniel Stutzbach] Just to be clear, this problem doesn't come up in round(), right? Right! It's unique to 2-argument mod-like functions. Because in round(), you just test the evenness of the last digit computed. There is never a need to compute extra digits just to perform the test. Right, round has to compute the last (retained) digit in any case. For mod(x, y) (for various definitions of mod), the result is x - n*y (for various ways of defining an integer n), and there exist efficient ways to determine the final result without learning anything about the value of n in the process. For example, consider Python's pow(10, 1, 136). It goes very fast to compute the answer 120, but internally Python never develops any idea about the value of n such that 10**1 - 136*n = 120. Is n even or odd? remainder-near can care, but there's no efficient way I know of to find out (dividing a 100-million digit integer by 136 to find out isn't efficient ;-)). ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Return type of round, floor, and ceil in 2.6
[Tim] I agree it's far from obvious to most how to accomplish rounding using the decimal facilities. FWIW, there is an entry for this in the Decimal FAQ: http://docs.python.org/lib/decimal-faq.html Raymond ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Return type of round, floor, and ceil in 2.6
On Jan 3, 2008 10:37 AM, Guido van Rossum [EMAIL PROTECTED] wrote:
Well, as issue 1689 states, the backporting was commited by Jeffrey on
rev 5967 [2], so this is the time to understand if we want this or
not.
This is a problem. Right now, in the trunk, math.float(1) returns 1,
where it should return 1.0 for compatibility with 2.5. Jeffrey, can
you fix this and similar incompatibilities you introduced?
Whoops! I've committed r59707 to fix math.{floor,ceil}. Let me know if
you find any other problems. ... Hmm. I've also changed the behavior
of round(2.5). I'll change that back tomorrow morning.
I haven't seen any answers to the original question. It looks like
Decimal is decided by 2.5 too: return a float from everything.
Rational, being a completely new type, is up to you guys, but because
new support for the conversion routines seems to be rare, it's
probably best to have it return floats too.
--
Namasté,
Jeffrey Yasskin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Return type of round, floor, and ceil in 2.6
2008/1/4, Jeffrey Yasskin [EMAIL PROTECTED]: I haven't seen any answers to the original question. It looks like Decimal is decided by 2.5 too: return a float from everything. Rational, being a completely new type, is up to you guys, but because new support for the conversion routines seems to be rare, it's probably best to have it return floats too. Sorry, I didn't understand this parragraph. Do you mean that the response in the following case is of type float?: round(decimal.Decimal(2.5)) 3.0 Regards, -- .Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Return type of round, floor, and ceil in 2.6
On Jan 4, 2008 12:13 AM, Jeffrey Yasskin [EMAIL PROTECTED] wrote:
On Jan 3, 2008 10:37 AM, Guido van Rossum [EMAIL PROTECTED] wrote:
Well, as issue 1689 states, the backporting was commited by Jeffrey on
rev 5967 [2], so this is the time to understand if we want this or
not.
This is a problem. Right now, in the trunk, math.float(1) returns 1,
where it should return 1.0 for compatibility with 2.5. Jeffrey, can
you fix this and similar incompatibilities you introduced?
Whoops! I've committed r59707 to fix math.{floor,ceil}. Let me know if
you find any other problems. ... Hmm. I've also changed the behavior
of round(2.5). I'll change that back tomorrow morning.
Looks like in Python 2.6, round(0.5) right now returns 0.0, whereas in
2.5, it returns 1.0.
I think it should return 1.0, for best compatibility with Python 2.5.
I haven't seen any answers to the original question. It looks like
Decimal is decided by 2.5 too: return a float from everything.
Right.
Rational, being a completely new type, is up to you guys, but because
new support for the conversion routines seems to be rare, it's
probably best to have it return floats too.
I think the pre-3.0 rule should be: round(), math.floor(), math.ceil()
*always* return a float.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Return type of round, floor, and ceil in 2.6
On Jan 4, 2008 11:14 AM, Jeffrey Yasskin [EMAIL PROTECTED] wrote: On Jan 4, 2008 4:40 AM, Facundo Batista [EMAIL PROTECTED] wrote: Do you mean that the response in the following case is of type float?: round(decimal.Decimal(2.5)) 3.0 Yes. That seems a little peculiar to me: wouldn't it be more natural to have round(Decimal_instance) return another Decimal? Mark ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Return type of round, floor, and ceil in 2.6
2008/1/4, Mark Dickinson [EMAIL PROTECTED]: That seems a little peculiar to me: wouldn't it be more natural to have round(Decimal_instance) return another Decimal? Yes. Now I find that now round() delegates its work to __round__: http://docs.python.org/dev/library/functions.html#round This doc says that round() Return the floating point value x rounded to n digits after the decimal point.. It don't specify if its binary or decimal floating point, ;) Feel free to create an issue and assign to me if you think that this should be done. Regards, -- .Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Return type of round, floor, and ceil in 2.6
On Jan 4, 2008 4:40 AM, Facundo Batista [EMAIL PROTECTED] wrote: 2008/1/4, Jeffrey Yasskin [EMAIL PROTECTED]: I haven't seen any answers to the original question. It looks like Decimal is decided by 2.5 too: return a float from everything. Rational, being a completely new type, is up to you guys, but because new support for the conversion routines seems to be rare, it's probably best to have it return floats too. Sorry, I didn't understand this parragraph. Do you mean that the response in the following case is of type float?: round(decimal.Decimal(2.5)) 3.0 Yes. -- Namasté, Jeffrey Yasskin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Return type of round, floor, and ceil in 2.6
Guido Looks like in Python 2.6, round(0.5) right now returns 0.0, Guido whereas in 2.5, it returns 1.0. Guido I think it should return 1.0, for best compatibility with Python Guido 2.5. And for best compatibility with everything else! 0.5 wink Skip ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Return type of round, floor, and ceil in 2.6
On Jan 4, 2008 8:58 AM, [EMAIL PROTECTED] wrote: Guido Looks like in Python 2.6, round(0.5) right now returns 0.0, Guido whereas in 2.5, it returns 1.0. Guido I think it should return 1.0, for best compatibility with Python Guido 2.5. And for best compatibility with everything else! 0.5 wink Should I round that to 0 whole winks or 1 whole wink? Rounding 0.5 to 0 is a new fad, called round-to-even, or statistician's rounding. Read http://en.wikipedia.org/wiki/Rounding . It's a standard, and more correct when doing statistical calculations. That's why we've chosen it for Python 3.0. But it should not bleed into Python 2.6. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Return type of round, floor, and ceil in 2.6
Guido Rounding 0.5 to 0 is a new fad, called round-to-even, or Guido statistician's rounding. Read Guido http://en.wikipedia.org/wiki/Rounding . It's a standard, and Guido more correct when doing statistical calculations. That's why Guido we've chosen it for Python 3.0. But it should not bleed into Guido Python 2.6. Thanks for the pointer. Given that it's been an ASTM standard since 1940 and apparently in fairly common use since the early 1900s, I wonder why it's not been more widely used in the past in programming languages. Skip ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Return type of round, floor, and ceil in 2.6
On Jan 4, 2008 8:37 AM, Facundo Batista [EMAIL PROTECTED] wrote: 2008/1/4, Mark Dickinson [EMAIL PROTECTED]: That seems a little peculiar to me: wouldn't it be more natural to have round(Decimal_instance) return another Decimal? Yes. Now I find that now round() delegates its work to __round__: http://docs.python.org/dev/library/functions.html#round This doc says that round() Return the floating point value x rounded to n digits after the decimal point.. It don't specify if its binary or decimal floating point, ;) Feel free to create an issue and assign to me if you think that this should be done. In 3.0, round() of a Decimal should return an int if invoked with 1 arg, a Decimal if invoked with 2. Similar for round() of a float. round() of an int can always return an int. In 2.6, round() should always return a float, regardless of the type of the first arg or the arg count, for best compatibility with 2.5. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Return type of round, floor, and ceil in 2.6
[EMAIL PROTECTED] Thanks for the pointer. Given that it's [round-to-even[ been an ASTM standard since 1940 and apparently in fairly common use since the early 1900s, I wonder why it's not been more widely used in the past in programming languages. Because add a half and chop was also in wide use for even longer, is also (Wikipedia notwithstanding) part of many standards (for example, the US IRS requires it if you do your taxes under the round to whole dollars option), and-- probably the real driver --is a little cheaper to implement for normal sized floats. Curiously, round-to-nearest can be unboundedly more expensive to implement in some obscure contexts when floats can have very large exponents (as they can in Python's decimal module -- this is why the proposed decimal standard allows operations like remainder-near to fail if applied to inputs that are too far apart: http://www2.hursley.ibm.com/decimal/daops.html#footnote.8 The secret reason is that it can be unboundedly more expensive to determine the last bit of the quotient (to see whether it's even or odd) than to determine an exact remainder). ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Return type of round, floor, and ceil in 2.6
On Jan 4, 2008 9:25 AM, [EMAIL PROTECTED] wrote: Guido Rounding 0.5 to 0 is a new fad, called round-to-even, or Guido statistician's rounding. Read Guido http://en.wikipedia.org/wiki/Rounding . It's a standard, and Guido more correct when doing statistical calculations. That's why Guido we've chosen it for Python 3.0. But it should not bleed into Guido Python 2.6. Thanks for the pointer. Given that it's been an ASTM standard since 1940 and apparently in fairly common use since the early 1900s, I wonder why it's not been more widely used in the past in programming languages. Because programming language designers rarely are statisticians? -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Return type of round, floor, and ceil in 2.6
On Jan 4, 2008 11:31 AM, Tim Peters [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] Thanks for the pointer. Given that it's [round-to-even[ been an ASTM standard since 1940 and apparently in fairly common use since the early 1900s, I wonder why it's not been more widely used in the past in programming languages. Because add a half and chop was also in wide use for even longer, is also (Wikipedia notwithstanding) part of many standards (for example, the US IRS requires it if you do your taxes under the round to whole dollars option), and-- probably the real driver --is a little cheaper to implement for normal sized floats. Curiously, round-to-nearest can be unboundedly more expensive to implement in some obscure contexts when floats can have very large exponents (as they can in Python's decimal module -- this is why the proposed decimal standard allows operations like remainder-near to fail if applied to inputs that are too far apart: http://www2.hursley.ibm.com/decimal/daops.html#footnote.8 The secret reason is that it can be unboundedly more expensive to determine the last bit of the quotient (to see whether it's even or odd) than to determine an exact remainder). Wow. Do you have an opinion as to whether we should adopt round-to-even at all (as a default)? -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Return type of round, floor, and ceil in 2.6
[GvR to Tim] Do you have an opinion as to whether we should adopt round-to-even at all (as a default)? For the sake of other implementations (Jython, etc) and for ease of reproducing the results with other tools (Excel, etc), the simplest choice is int(x+0.5). That works everywhere, it is easy to explain, it runs fast, and it is not hard to get right. my two cents, Raymond ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Return type of round, floor, and ceil in 2.6
On 4 Jan, 10:45 pm, [EMAIL PROTECTED] wrote: [GvR to Tim] Do you have an opinion as to whether we should adopt round-to-even at all (as a default)? For the sake of other implementations (Jython, etc) and for ease of reproducing the results with other tools (Excel, etc), the simplest choice is int(x+0.5). That works everywhere, it is easy to explain, it runs fast, and it is not hard to get right. I agree for the default. Except the part where Excel, Jython, and Python's current round, actually use sign(x) * int(abs(x)+0.5), so maybe it's not *completely* easy to get right ;-). Having other rounding methods *available*, though, would be neat. The only application I've ever worked on where I cared about the difference, the user had to select it (since accounting requirements differ by jurisdiction and, apparently, by bank preference). Having a standard way to express this (especially if it worked across different numeric types, but perhaps I digress) would be pleasant. Implementing stochastic rounding and banker's rounding oneself, while not exactly hard, is a drag. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Return type of round, floor, and ceil in 2.6
Consistency and compatibility with 3.0 suggest that they should return long for every new type we add them to. What does the list think? I think Py2.6 and Py2.5 should be treated with more respect. Will backporting this change can only cause relief or create headaches?. By definition, the Py3.0 release was supposed to be the one big incompatible set of changes. Backporting with a goal of consistency and compatibility with 3.0 suggests that the backporters may have lost their compass. FWIW, Py2.6 hasn't been released yet and no one *has* to upgrade to it. So, if it is to have any chance of success, it needs to be a better Python than 2.5. IMO, jamming 3.0 junk into 2.x just provides an incentive to skip the upgrade altogether. In the press release for 2.6, we need to be able to say something stronger than: filled with deprecations, two ways to do everything, dozens of tiny incompatibilities all done in the name of 3.0, and runs slower. I think there ought to be a much more agressive standard for 3.0 backports:, does the proposed backport make 2.6 more attractive? Remember, for large code bases, upgrading is a PITA (I think Google is still running tons of code on 2.2, 2.3, and 2.4). There needs to be a good incentive for upgrading; otherwise, Py2.6 *will* fail. The specific change suggested here is possibly (and perhaps probably) harmless; however, it is part of a larger trend that is not healthy for the 2.x series. Raymond ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Return type of round, floor, and ceil in 2.6
2008/1/3, Raymond Hettinger [EMAIL PROTECTED]: I think Py2.6 and Py2.5 should be treated with more respect. Will backporting this change can only cause relief or create headaches?. By definition, the Py3.0 release was supposed to be the one big incompatible set of changes. Backporting with a goal Well, as issue 1689 states, the backporting was commited by Jeffrey on rev 5967 [2], so this is the time to understand if we want this or not. Personally, I'm -0. I was involved in this because of Decimal, but I can grow some __methods__ in it that can be in the trunk, unused, and when ported to 3k fit ok in the new infrastructure. Regards, [1] http://bugs.python.org/issue1689 [2] http://svn.python.org/view?rev=59671view=rev -- .Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Return type of round, floor, and ceil in 2.6
I think there ought to be a much more agressive standard for 3.0 backports:, does the proposed backport make 2.6 more attractive? Remember, for large code bases, upgrading is a PITA (I think Google is still running tons of code on 2.2, 2.3, and 2.4). There needs to be a good incentive for upgrading; otherwise, Py2.6 *will* fail. Very well put, Raymond. I wonder, though, whether the appearance of a viable 3.0 will essentially kill the demand for 2.6? Bill ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Return type of round, floor, and ceil in 2.6
[GvR] We're thin on contributors as it is (have you noticed how few people are submitting anything at all lately?). The people who are contributing are doing a nice job. Also, it was nice that the change was discussed on the list. 2.6 should be extremely compatible with 2.5 by default. Good to hear that is still a primary goal. Along the way, I worried that that sentiment had been lost and that little incompatibilities were sneaking in (iirc, the proposed transition plan for leading zeroes was headed down this path). The incentive for upgrading will be you can reach 3.0 easier via 2.6 and perhaps the latest version of 3rd party software X runs best on 2.6. Does the 2to3 tool work from 2.5 or from 2.6 or does it make difference? If it works from 2.5, I'm thinking my company will make the jump all at once (after the 3.x series stabilizes, gets optimized, and key third-party packages have been migrated). I'm also expecting that some chuck of users will be left in the 2.x world and that they would like highest version to be as clean as possible (with migration features going into the category of things that don't provide them any benefit). Right now, in the trunk, math.float(1) returns 1, where it should return 1.0 for compatibility with 2.5. Jeffrey, can you fix this and similar incompatibilities you introduced? Thanks for zapping this. Raymond ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Return type of round, floor, and ceil in 2.6
Raymond Hettinger wrote: Does the 2to3 tool work from 2.5 or from 2.6 or does it make difference? If it works from 2.5, I'm thinking my company will make the jump all at once (after the 3.x series stabilizes, gets optimized, and key third-party packages have been migrated). It's not guaranteed that it will work from 2.5. The transition plan for 2to3 is: * Get your code working under python2.6 -3 without Python 3.0 deprecation warnings * Use 2to3 to migrate the code from 2.6 to 3.0 Christian ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Return type of round, floor, and ceil in 2.6
On Jan 3, 2008 1:13 PM, Raymond Hettinger [EMAIL PROTECTED] wrote: [GvR] We're thin on contributors as it is (have you noticed how few people are submitting anything at all lately?). The people who are contributing are doing a nice job. Also, it was nice that the change was discussed on the list. We can always use more contributors! (See separate thread.) 2.6 should be extremely compatible with 2.5 by default. Good to hear that is still a primary goal. Along the way, I worried that that sentiment had been lost and that little incompatibilities were sneaking in (iirc, the proposed transition plan for leading zeroes was headed down this path). I don't recall vetting (or even seeing) that plan! Without the -3 option, 2.6 should accept the same syntax (or a superset) as 2.5. With the -3 flag, however, you may get warnings about stuff that changes in 3.0. I don't like that -3 would change the accepted syntax; for that, we should use from __future__ import A hypothetical example for octal numbers: I propose that bare 2.6 accepts either 0777 and 0o777 as octal literals. If you use python -3, you might get a warning about using 0777, although this is borderline useless since 2to3 will take care of it just fine. If people think it's worth it (I doubt it for this example) we could add from __future__ import octal_literals which would prohibit 0777 altogether. The incentive for upgrading will be you can reach 3.0 easier via 2.6 and perhaps the latest version of 3rd party software X runs best on 2.6. Does the 2to3 tool work from 2.5 or from 2.6 or does it make difference? If it works from 2.5, I'm thinking my company will make the jump all at once (after the 3.x series stabilizes, gets optimized, and key third-party packages have been migrated). The 2to3 tool works from either baseline, but there is lots of stuff it can't deal with (basically because 2to3 doesn't do type inference, and it's unlikely that it ever will). In 2.6, the -3 warnings will help you find stuff that you should transform yourself. (Usually there is a transformation that will do the right thing in 2.6 and which will, after conversion by 2to3, continue to do the right thing in 3.0.) I'm also expecting that some chuck of users will be left in the 2.x world and that they would like highest version to be as clean as possible (with migration features going into the category of things that don't provide them any benefit). They could either stick with 2.5 (or at least insist on compatibility with 2.5) or use 2.6 without the -3 flag. They might benefit from the migration features 5 years from now, and until then they shouldn't hurt. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
