summaryrefslogtreecommitdiffstats
path: root/Lib/_pylong.py
Commit message (Collapse)AuthorAgeFilesLines
* Fix typos in comments and test code (#122846)Xie Yanbo2024-08-121-4/+4
|
* gh-119057: Use better error messages for zero division (#119066)Nikita Sobolev2024-06-031-1/+1
|
* gh-118750: Asymptotically faster `int(string)` (#118751)Tim Peters2024-05-191-33/+399
| | | | | | | | | | | | | | | Asymptotically faster (O(n log n)) str->int for very large strings, leveraging the faster multiplication scheme in the C-coded `_decimal` when available. This is used instead of the current Karatsuba-limited method starting at 2 million digits. Lots of opportunity remains for fine-tuning. Good targets include changing BYTELIM, and possibly changing the internal output base (from 256 to a higher number of bytes). Doing this was substantial work, and many of the new lines are actually comments giving correctness proofs. The obvious approaches sticking to integers were too slow to be useful, so this is doing variable-precision decimal floating-point arithmetic. Much faster, but worst-possible rounding errors have to be wholly accounted for, using as little precision as possible. Special thanks to Serhiy Storchaka for asking many good questions in his code reviews! Co-authored-by: Jelle Zijlstra <jelle.zijlstra@gmail.com> Co-authored-by: sstandre <43125375+sstandre@users.noreply.github.com> Co-authored-by: Pieter Eendebak <pieter.eendebak@gmail.com> Co-authored-by: Nice Zombies <nineteendo19d0@gmail.com>
* gh-118610: Centralize power caching in `_pylong.py` (#118611)Tim Peters2024-05-081-67/+101
| | | | | A new `compute_powers()` function computes all and only the powers of the base the various base-conversion functions need, as efficiently as reasonably possible (turns out that invoking `**`is needed at most once). This typically gives a few % speedup, but the primary point is to simplify the base-conversion functions, which no longer need their own, ad hoc, and less efficient power-caching schemes. Co-authored-by: Serhiy Storchaka <storchaka@gmail.com>
* gh-118164: Break a loop between _pydecimal and _pylong and optimize int to ↵Serhiy Storchaka2024-05-051-1/+45
| | | | | | | | | | | | | | | | | | | | str conversion (GH-118483) For converting large ints to strings, CPython invokes a function in _pylong.py, which uses the decimal module to implement an asymptotically waaaaay sub-quadratic algorithm. But if the C decimal module isn't available, CPython uses _pydecimal.py instead. Which in turn frequently does str(int). If the int is very large, _pylong ends up doing the work, which in turn asks decimal to do "big" arithmetic, which in turn calls str(big_int), which in turn ... it can become infinite mutual recursion. This change introduces a different int->str function that doesn't use decimal. It's asymptotically worse, "Karatsuba time" instead of quadratic time, so still a huge improvement. _pylong switches to that when the C decimal isn't available. It is also used for not too large integers (less than 450_000 bits), where it is faster (up to 2 times for 30_000 bits) than the asymptotically better implementation that uses the C decimal. Co-authored-by: Tim Peters <tim.peters@gmail.com>
* gh-102515: Remove unused imports in the `Lib/` directory (#102516)Alex Waygood2023-03-081-1/+0
|
* gh-90716: Remove _pylong._DEBUG flag (#99063)Victor Stinner2022-11-031-9/+0
| | | | To debug the _pylong module, it's trivial to add this code again locally. There is not need to keep it in Python releases.
* gh-90716: add _pylong.py module (#96673)Neil Schemenauer2022-10-261-0/+295
Add Python implementations of certain longobject.c functions. These use asymptotically faster algorithms that can be used for operations on integers with many digits. In those cases, the performance overhead of the Python implementation is not significant since the asymptotic behavior is what dominates runtime. Functions provided by this module should be considered private and not part of any public API. Co-author: Tim Peters <tim.peters@gmail.com> Co-author: Mark Dickinson <dickinsm@gmail.com> Co-author: Bjorn Martinsson