"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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4