On Mar 23, 5:42 pm, Steven D'Aprano <st...@remove-this-
cybersource.com.au> wrote:
> On Mon, 23 Mar 2009 10:06:23 -0700, Mensanator wrote:
> > On Mar 23, 5:48 am, Steven D'Aprano <st...@remove-this-
> > cybersource.com.au> wrote:
> >> On Mon, 23 Mar 2009 01:45:53 -0700, Mensanator wrote:
> >> >> but you can create a helper
> >> >> function very easily:
>
> >> >> def round(dec, places, rounding=decimal.ROUND_HALF_UP): return
> >> >> dec.quantize(decimal.Decimal(str(10**-places)), rounding)
>
> >> > Still ugly. I would do this:
>
> >> >>>> a = Decimal('1.23456789')
>
> >> >>>> for i in xrange(1,6):
> >> > print Context.create_decimal(Context(i,ROUND_DOWN),a)
>
> >> Well, that's hardly any less ugly.
>
> > I wouldn't say so since there are no strings attached. Didn't the OP
> > specifically ask for a solution that didn't involve strings?
>
> No, the OP asked for a solution that didn't involve converting the
> decimal number to a string first.
>
> Besides, I don't believe you can specify the rounding mode unless you use
> strings *wink*
>
> >>> type(ROUND_DOWN)
>
> <type 'str'>
>
> >> And it also gives different results to my function: my function rounds
> >> to <places> decimal places, yours to <i> digits. Very different things.
>
> > Yeah, I know all about that. I work in Environmental Remediation. That's
> > real science, where rounding to decimal places is strictly forbidden,
> > significant digits must be preserved. That means rounding to digits.
>
> Okay, so in other words you solved your problem rather than the OP's
> problem.
People other than the OP read these threads. Do you want to
give people the impression that quantize is the only option?
>
> > Do
> > you know what kind of hoops I have to jump through to get Access or
> > Excel to round properly when doing unit conversion?
>
> I feel your pain.
So surely you don't want to give the impression that
all Decimal is good for is emulating Excel?
>
> > Surely you're not so maive that you think dividing by 1000 simply moves
> > the decimal point three places?
>
> Of course it does, if you're using real numbers.
Computers have real numbers?
> If you're using floats,
> no, not quite, there are rounding issues involved, and underflow.
And that's why we have Decimal, right?
>
> I'm not sure why you raise this. Is this a general rant, or do you have a
> specific criticism?
At first, I could not understand the need for nor the syntax of
quantize. It seemed very clunky having to specify a template and
a rounding, especially since it also accepts a Context object.
And upon seeing Context.create_decimal, I thought "why would
I ever use quantize when I can do it the 'right' way?"
But that was when I first saw it, so the rant isn't about
which way to do something, but pointing out there may be
other solutions that are more appropriate to the problem.
Speaking of doing things the 'right' way, I seem to have
blundered my way into the answer I was looking for. According
to the documention
<quote>
create_decimal(num)
Creates a new Decimal instance from num but using self as context.
Unlike the Decimal constructor, the context precision, rounding
method, flags, and traps are applied to the conversion.
</quote>
and that's exactly what I want. I may have one context for
calculation and another for printing, so I want to be able
to programatically impose my printing context on a number
without affecting it.
Of course it didn't work.
>>> Context.create_decimal('1.234456789')
Traceback (most recent call last):
File "<pyshell#13>", line 1, in <module>
Context.create_decimal('1.234456789')
TypeError: unbound method create_decimal() must be called with Context
instance as first argument (got str instance instead)
Ok, the Traceback says I need a Context instance, so I tried
>>> Context.create_decimal(Context(4),'1.234456789')
Decimal('1.234')
So I thought ok, but what's this self referred to in the docs
and why does it say "create_decimal(num)" if I have to have a
Context instance as the first parameter?
But wait, the Traceback also says "unbound method". Was I supposed
to have parentheses after Context?
>>> Context().create_decimal('1.234456789')
Decimal('1.234456789')
Duh.
The self must refer to the default Context that's in place.
Providing I use the bound method.
If I had done it the right way from the start I would have gotten
a precision of 28 (unless I mucked around with the default Context)
and probably would never have figured out that with an unbound
method I could impose a Context on a number on the fly.
Man, that's subtle.
>
> --
> Steven
--
http://mail.python.org/mailman/listinfo/python-list
