Michael McLay wrote:
>
> Those were easy. How would the following be interpreted?
>
> decimal 3.404, 2)
> decimal 3.405, 2)
> decimal(3.39999, 2)
>
> [...]
>
> For addition, subtraction, and multiplication the results would be
> exact with no rounding of the results. Calculations that include
> division the number of digits in a non-terminating result will have to
> be explicitly set. Would it make sense for this to be definedby the
> numbers used in the calculation? Could this be set in the module or
> could it be global for the application?
This is why Cowlishaw et al require a full context for all operations.
At one point I tried implementing things with the context being
contained in the number rather than "global" (which actually means
thread-global, but I'm probably punting on *that* bit for the moment),
but Tim Peters persuaded me that sticking with the spec was the Right
Thing until *after* the spec was fully implemented.
After seeing the mess generated by PEP-238, I'm fervently in favor of
sticking with external specs whenever possible.
--
--- Aahz (@pobox.com)
Hugs and backrubs -- I break Rule 6 <*> http://www.rahul.net/aahz/
Androgynous poly kinky vanilla queer het Pythonista
I don't really mind a person having the last whine, but I do mind someone
else having the last self-righteous whine.
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