bpo-26256: Document algorithm speed for the Decimal module.

[csabella]

https://bugs.python.org/issue26256

[vstinner]

Cpython => CPython

[vstinner]

LGTM. But I would prefer that @skrah review it, since I'm not use of the context.

@skrah: Would you mind to review this change?

[skrah]

Thanks, that looks great! Small nitpick: C/CFFI versions. PyPy uses CFFI, I think that is a little clearer.

[csabella]

Thank Stefan! I've added that change.

[bedevere-bot]

@skrah: Please replace # with GH- in the commit message next time. Thanks!

[skrah]

Ok, thanks!

[miss-islington]

Thanks @csabella for the PR, and @skrah for merging it 🌮🎉.. I'm working now to backport this PR to: 3.7.
🐍🍒⛏🤖

[bedevere-bot]

GH-11736 is a backport of this pull request to the 3.7 branch.

[vstinner]

I'm sorry but I don't understand the added FAQ entry. Does it mean that decimal is slow by default unless I enable unlimited precision?

import decimal
import tracemalloc
tracemalloc.start()
if 0:
    ctx = decimal.getcontext()
    ctx.prec = decimal.MAX_PREC
    ctx.Emax = decimal.MAX_EMAX
    ctx.Emin = decimal.MIN_EMIN
num = decimal.Decimal(1) / decimal.Decimal(7)
mem = tracemalloc.get_traced_memory()[1]
print("Peak memory usage: %.1f kB" % mem)

On my Fedora 29, this script displays "Peak memory usage: 864.0 kB".

But if I replace "if 0:" with "if 1:", the script fails immediately with:

Traceback (most recent call last):
  File "dec.py", line 9, in <module>
    num = decimal.Decimal(1) / decimal.Decimal(7)
MemoryError

[skrah]

On Tue, Feb 12, 2019 at 06:17:15AM -0800, Victor Stinner wrote: Does it mean that decimal is slow by default unless I enable **unlimited** precision?

No, but I can see why you get the impression from the new FAQ entry. I hoped people would infer the intended meaning. "to realize this performance gain" here means: If you don't set for unrounded precision, you'll simply get a result that's rounded to, say, 28 digits instead of the desired unrounded integer. It could be replaced by "in order to get an unrounded exact integer result".

But if I replace "if 0:" with "if 1:", the script fails immediately with: ``` Traceback (most recent call last): File "dec.py", line 9, in <module> num = decimal.Decimal(1) / decimal.Decimal(7) MemoryError

Yes, because you don't have enough memory for decimal.MAX_PREC digits.

[vstinner]

However, to realize this performance gain, the context needs to be set for unrounded calculations.

I understand: if you don't use "ctx.prec = decimal.MAX_PREC", decimal will be very slow.

It could be replaced by "in order to get an unrounded exact integer result".

I'm confused. The FAQ entry is about performance. I don't understand the relationship between performance and correctness.

[skrah]

On Tue, Feb 12, 2019 at 06:48:57AM -0800, Victor Stinner wrote: > However, to realize this performance gain, the context needs to be set for unrounded calculations. I understand: if you don't use "ctx.prec = decimal.MAX_PREC", decimal will be very slow. > It could be replaced by "in order to get an unrounded exact integer result". I'm confused. The FAQ entry is about performance. I don't understand the relationship between performance and correctness.

Then why did you approve the original entry? This is just wasting time.

[vstinner]

Then why did you approve the original entry?

Sorry, I don't recall the history of this PR created longer than 1 year ago. It seems like the PR evolved after I approved it, and I asked you explicitly to review you since I don't know well decimal internals.

I approved the idea of documenting decimal performance, as discussed in https://bugs.python.org/issue26256

This is just wasting time.

I don't think that it's useful to be rude here.

[vstinner]

"to realize this performance gain" here means: If you don't set for unrounded precision, you'll simply get a result that's rounded to, say, 28 digits instead of the desired unrounded integer.

Maybe the FAQ entry can be rephrased to avoid confusion. But since I still don't understand very well the subtle details, I cannot suggest a change.