math module for Decimals

[Fredrik Johansson]

Oh boy, now I will finally prove myself illiterate... well, so be it.
But i am after the extra precision:



Agree: sin, cos and atan would do it.

FYI, mpmath (http://code.google.com/p/mpmath/) implements arbitrary-
precision standard transcendental functions in pure Python. It is much
faster than decimal, dmath, decimalfuncs and AJDecimalMathAdditions,
and handles huge arguments just fine.

Fredrik

 

[Mark Dickinson]

FYI, mpmath (http://code.google.com/p/mpmath/) implements arbitrary-
precision standard transcendental functions in pure Python. It is much
faster than decimal, dmath, decimalfuncs and AJDecimalMathAdditions,
and handles huge arguments just fine.

Yes, I think mpmath was mentioned already somewhere above;
it sounds like a perfect tool for the OP's requirements.

Note that it's still subject to the same limitations as anything
else for trig_function(really huge argument), of course:
[... still waiting for a result 30 minutes later ...]

(not a criticism of mpmath: just a demonstration that this
really is pretty much unavoidable).

Out of curiosity, what sort of guarantees does mpmath give on
error bounds? It looks like it aims for 'almost correctly
rounded'; i.e., error < 0.500...001 ulps.

Here's one place in mpmath where it looks as though more
internal precision is needed (with default settings: 53-bit
precision, etc.)
mpc(real='0.0', imag='0.9272952180016123')

Shouldn't the real part here be something like:

2.2204460492503132e-17

instead of 0.0?

Mark

 

[Fredrik Johansson]

Note that it's still subject to the same limitations as anything
else for trig_function(really huge argument), of course:

[... still waiting for a result 30 minutes later ...]

(not a criticism of mpmath: just a demonstration that this
really is pretty much unavoidable).

Indeed. That's asking for 1 billion digits of pi.

(I feel that I need to point out that mpmath really does go out of its
way to make ridiculous things like that work, though. It uses a very
fast algorithm to compute pi, faster than MPFR even. Assuming gmpy is
installed on the system and enough RAM, cos('1e999999999') should
finish in about 10^5 seconds = 1 day (based on extrapolation on my
computer). You just weren't patient enough

Out of curiosity, what sort of guarantees does mpmath give on
error bounds? It looks like it aims for 'almost correctly
rounded'; i.e., error < 0.500...001 ulps.

Sort of; there are different standards of rigor. The basic arithmetic
operations are correctly rounded. The elementary functions are 'almost
correctly rounded' in the sense you described (subject to the usual
bug disclaimer); they are also correctly rounded around some zeros and
poles (e.g. sin(x) for sufficiently small x properly rounds to x or x*
(1-eps) if upward/downward rounding is used).

Some other functions like erf and gamma are 'almost correctly rounded'
for real arguments, but currently no attempt is made to correct for
cancellations in real/imaginary parts (this problem is mostly avoided
for elementary functions by decomposition into real-valued functions
like cos(a+b*i) = cos(a)*cosh(b)-sin(a)*sinh(b)*i). Finally, some
"higher" functions are computed more naively and can easily be forced
to lose accuracy by finding large arguments that correspond to small
function values.

It would indeed be nice to support correct rounding for at least the
elementary transcendental functions in the future. One advantage of
arbitrary precision is that the user can compensate for rounding
errors very easily by just increasing the working precision, but
ideally that shouldn't be necessary for atomic operations.

Here's one place in mpmath where it looks as though more
internal precision is needed (with default settings: 53-bit
precision, etc.)


mpc(real='0.0', imag='0.9272952180016123')

Shouldn't the real part here be something like:

2.2204460492503132e-17

instead of 0.0?

That's certainly a bug; it should be fixed soon.

Fredrik