[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@p
[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 i
> 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?
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
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
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 signi
[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 con
[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
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 si
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
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 requirem
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
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.
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 upda
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 J
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,
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
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
___
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
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 w
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:
> > > > > We
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
> >reprodu
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
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
> > > > r
24 matches
Mail list logo
