[Python-Dev] calculator module

[Tim Peters]

[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).