[Gareth McCaughan] >> Further, I'd argue that since Decimal can work with numbers >> of arbitrary precision, an implementation of (say) exp that >> works on Decimals ought to work with something like full precision, >> unless it's *only* intended for casual use. Writing implementations >> of all these things would be a considerable amount of work. [Batista, Facundo] > You always can change the context precision before the operation. But > it's not very normal to the user that comes from using a "hand > calculator". Except the user isn't responsible for calculating exp(), that problem belongs to the system exp() implementation. The bulk of context features are really for the benefit of library writers, and temporarily boosting precision within library functions is a conventional way to proceed. Hand calculators also do this under the covers. For example, HP's current top-end calculator displays 12 decimal digits, but always uses (at least) 15 decimal digits internally. The HP *user* doesn't have to do anything to get a good-to-the-12th-digit exp() result beyond pressing the EXP key. A huge advantage of using a standard-conforming implementation of a standard arithmetic (which IBM's decimal proposal aims to be) is that high quality arbitrary-but-fixed precision implementations of "advanced" functions written to that standard will eventually appear, giving the same results on all platforms implementing that standard, and written by experts all over the world (not just by the relative handful of Python library writers, or the teensy subset of those experienced in coding all-purpose library-strength numerics).
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