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
