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] Repeatability of looping over dicts
Guido What code would break if we loosened this restriction? I don't know how much, but I do know I've relied on this behavior before. (In fact, I've asked about it before.) I guess the counter question to yours would be, What would be gained by loosening this restriction? If the answer is, not much, then I don't see why this is even an idle thought. 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 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] Repeatability of looping over dicts
On Jan 5, 2008 6:58 AM, [EMAIL PROTECTED] wrote: Guido What code would break if we loosened this restriction? I don't know how much, but I do know I've relied on this behavior before. (In fact, I've asked about it before.) I guess the counter question to yours would be, What would be gained by loosening this restriction? If the answer is, not much, then I don't see why this is even an idle thought. It sounds like loosening the restriction would allow Jython to use an implementation that is more efficient when used concurrently. That may not be sufficient reason; Jython apps that need a more efficient concurrent dict could import the ConcurrentHashMap class directly, and CPython apps are out of luck anyway. -- --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] Contributing to Python
On Fri, Jan 04, 2008 at 11:45:34PM -0800, Mike Klaas wrote: Question: should patches include edits to whatsnew.rst, or is the committer responsible for adding a note? It's OK to submit or commit patches that don't update whatsnew.rst; I'll notice the checkin and decide whether to include the change. --amk ___ 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
[Python-Dev] Return type of round, floor, and ceil in 2.6
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. http://en.wikipedia.org/wiki/Rounding --- Art Rasmussen ___ 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] Repeatability of looping over dicts
On Jan 4, 2008 12:05 PM, Tim Delaney [EMAIL PROTECTED] wrote: history of insertions and deletions. If items(), keys(), values(), iteritems(), iterkeys(), and itervalues() are called with no intervening modifications to the dictionary, the lists will directly correspond. I looked over the Java code briefly (http://gee.cs.oswego.edu/dl/classes/EDU/oswego/cs/dl/util/concurrent/ConcurrentHashMap.java:HashIterator) and I don't see anything that would cause it to violate this condition. In particular, the locks don't affect the order. It's a complicated class though, so I could have missed it. Do you see a reason for it to change its iteration order spontaneously? If another thread is concurrently modifying the dict, that's an intervening modification, and changing the iteration order is fine. There's the second question of whether using ConcurrentHashMap for python dicts is a good idea. I can't find any mention of thread-safety in the Jython docs, so I assume it follows Java's rules, which are that most variables must be locked in order to be accessed and modified concurrently. Making dict a ConcurrentHashMap would provide a stronger guarantee for some built-in types but not others, which is likely to confuse people. Further, not all synchronized maps can be replaced by ConcurrentHashMap because you may need groups of operations to be atomic, while CHM only provides atomicity across single method calls. I think a new ConcurrentDict class would probably be a better way to integrate ConcurrentHashMap. -- 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/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
[Python-Dev] Extend reST spec to allow automatic recognition of identifiers in comments?
This is a VERY VERY rough draft of a PEP. The idea is that there should be
some formal way that reST parsers can differentiate (in docstrings) between
variable/function names and identical English words, within comments.
PEP: XXX
Title: Catching unmarked identifiers in docstrings
Version: 0.0.0.0.1
Last-Modified: 23-Aug-2007
Author: Jameson Quinn firstname dot lastname at gmail
Status: Draft
Type: Informational
Content-Type: text/x-rst
Created: 23-Aug-2007
Post-History: 30-Aug-2002
Abstract
This PEP makes explicit some additional ways to parse docstrings and
comments
for python identifiers. These are intended to be implementable on their own
or
as extensions to reST, and to make as many existing docstrings
as possible usable by tools that change the visible
representation of identifiers, such as translating (non-english) code
editors
or visual programming environments. Docstrings in widely-used modules are
encouraged to use \`explicit backquotes\` to mark identifiers which are not
caught by these cases.
THIS IS AN EARLY DRAFT OF THIS PEP FOR DISCUSSION PURPOSES ONLY. ALL LOGIC
IS
INTENTIONALLY DEFINED ONLY BY EXAMPLES AND THERE IS NO REFERENCE
IMPLEMENTATION
UNTIL A THERE ARE AT LEAST GLIMMERINGS OF CONSENSUS ON THE RULE SET.
Rationale
=
Python, like most computer languages, is based on English. This can
represent a hurdle to those who do not speak English. Work is underway
on Bityi_, a code viewer/editor which translates code to another language
on load and save. Among the many design issues in Bityi is that of
identifiers in docstrings. A view which translates the identifiers in
code, but leaves the untranslated identifier in the docstrings, makes
the docstrings worse than useless, even if the programmer has a
rudimentary grasp of English. Yet if all identifiers in docstrings are
translated, there is the problem of overtranslation in either direction.
It is necessary to distinguish between the variable named variable,
which should be translated, and the comment that something is highly
variable, which should not.
.. _Bityi: http://wiki.laptop.org/go/Bityi
Note that this is just one use-case; syntax coloring and docstring
hyperlinks are another one. This PEP is not the place for a discussion of
all the pros
and cons of a translating viewer.
PEP 287 standardizes reST as an optional way to markup docstrings.
This includes the possibility of using \`backquotes\` to flag Python
identifiers. However, as this PEP is purely optional, there are many
cases of identifiers in docstrings which are not flagged as such.
Moreover, many of these unflagged cases could be caught programatically.
This would reduce the task of making a module internationally-viewable,
or hyperlinkable, considerably.
This syntax is kept relatively open to allow for reuse with
other programming languages.
Common cases of identifiers in docstrings
=
The most common case is that of lists of argument or
method names. We call these identifier lists::
def register(func, *targs, **kargs):
register a function to be executed someday
func - function to be called
targs - optional arguments to pass
kargs - optional keyword arguments to pass
#func, targs, and kargs would be recognized as identifiers in the
above.
class MyClass(object):
Just a silly demonstration, with some methods:
thisword : is a class method and you can call
it - it may even return a value.
As with reST, the associated text can have
several paragraphs.
BUT - you can't nest this construct, so BUT isn't counted.
anothermethod: is another method.
eventhis -- is counted as a method.
anynumber --- of dashes are allowed in this syntax
But consider: two words are NOT counted as an identifier.
things(that,look,like,functions): are functions (see below)
Also, the docstring may have explanatory text, below or by
itself: so we have to deal with that.
Thus, any paragraph which is NOT preceded by an empty line
or another identifier list - like itself above - does not count
as an identifier.
#thisword, anothermethod, eventhis, anynumber, and things would be
#recognized as identifiers in the above.
Another case is things which look like functions, lists, indexes, or
dicts::
afunction(is,a,word,with,parentheses)
[a,list,is,a,bunch,of,words,in,brackets]
anindex[is, like, a, cross, between, the, above]
{adict:is,just:words,in:curly, brackets: likethis}
#all of the above would be recogniszed as identifiers.
The syntax of what goes inside these is very loose.
identifier_list ::= [initial_word]opening_symbol content_word
{separator_symbol content_word} closing symbol
, with no whitespace after initial_word, and where separator_symbol is the
set of symbols .,{}[]+-*^%=|/()[]{} MINUS closing_symbol. content_word
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] Contributing to Python
Mike Klaas wrote: Question: should patches include edits to whatsnew.rst, or is the committer responsible for adding a note? A patch should contain edits for Misc/NEWS. Patches without documentation and NEWS updates costs the committer more time and reduces the likelihood of a commit. Even a perfect patch costs several minutes of our life time. The patch must be reviewed, applied, compiled, the entire unit test suite must pass and finally it must be committed and the issues needs to be closed, too. 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] Contributing to Python
On Jan 5, 2008 2:36 PM, Christian Heimes [EMAIL PROTECTED] wrote: Mike Klaas wrote: Question: should patches include edits to whatsnew.rst, or is the committer responsible for adding a note? A patch should contain edits for Misc/NEWS. Patches without documentation and NEWS updates costs the committer more time and reduces the likelihood of a commit. Even a perfect patch costs several minutes of our life time. The patch must be reviewed, applied, compiled, the entire unit test suite must pass and finally it must be committed and the issues needs to be closed, too. Several minutes?! The average perfect patch costs me more like between half an hour and an hour. -- --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 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
[Python-Dev] Rounding Decimals
On Jan 5, 2008 3:34 PM, Mark Dickinson [EMAIL PROTECTED] wrote: 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? I think pep 3141's round(x, ndigits) does (1). The only thing it doesn't support yet is specifying the rounding mode. Perhaps the pep should say that round() passes any extra named arguments on to the __round__() method so that users can specify a rounding mode for types that support it? The Real interface doesn't say anything about significant digits, so Decimal can do whatever we want. My first guess would be that round should remove significant digits but not add them. (i.e. round(3.199, 2) == 3.20 but round(3, 1) == 3.) As you know, I'm working on a patch to implement 3141 for Decimal at http://bugs.python.org/issue1623, which I'll update as soon as this thread comes to a conclusion. Other people who are interested in getting this right should add themselves to its nosy list so they can object before I check something dumb in. :) I currently plan to keep __round__ in 2.6's Decimal with 3.0's behavior because it no longer affects the round() builtin in 2.6. Users who want it can call it directly … or we might provide, in 2.6, a module that provides 3.0 versions of the core library functions that change behavior so that they can get the new round() explicitly. -- 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] Rounding Decimals
I think pep 3141's round(x, ndigits) does (1). The only thing it doesn't support yet is specifying the rounding mode. Perhaps the pep should say that round() passes any extra named arguments on to the __round__() method so that users can specify a rounding mode for types that support it? That would clutter the interface. Just specify a universal rounding mode for __round__ and have Decimal's implementation of that method comply. If someone wants more control than that, they can manipulate the decimal object directly. 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
[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
