[Python-Dev] Re: Decimal data type issues (original) (raw)
Paul Moore pf_moore at yahoo.co.uk
Wed Apr 21 03:50:12 EDT 2004
- Previous message: [Python-Dev] Re: Decimal data type issues
- Next message: [Python-Dev] Re: Decimal data type issues
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
"Tim Peters" <tim.one at comcast.net> writes:
[Paul Moore]
As a result of this, I'm not sure that it's valid to care about the internal representation of a Decimal instance. It's not quite right. While this is a floating-point arithmetic, it was designed to "preserve scale" so long as precision isn't exceeded. [...]
Tim, Thanks for taking the time to clarify this. I'm going to need to think about this some more to grasp the implications, but I see where it's intended to apply.
FWIW, my feeling now is that Kevin's requirement is something that can be handled by a subclass of Decimal, or a class which contains a Decimal. I'm not convinced by Kevin's suggestion that the operations needed are "hard" - code complexity can (and should) be encapsulated inside the subclass, and I don't see the need for runtime inefficiency. Specifically, I can't see why, if you can first get an (effectively, according to whatever rules you want to apply) exact Decimal representation of your "number", you can't do any further scaling and changing of precision, etc, entirely with Decimal instances, and with minimal loss of runtime efficiency.
Maybe a concrete example of what Kevin is after (I have a database background, so I'm happy if it's based around SQL NUMBER datatypes) would clarify his concerns.
Paul.
This signature intentionally left blank
- Previous message: [Python-Dev] Re: Decimal data type issues
- Next message: [Python-Dev] Re: Decimal data type issues
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]