bpo-37128: Add math.perm(). #13731
bpo-37128: Add math.perm(). #13731
Conversation
serhiy-storchaka
force-pushed
the
math-perm
branch
from
32dde04 to
4511c7a
Compare
|
@serhiy-storchaka Please could you open a new b.p.o. issue for |
serhiy-storchaka
changed the title
Doc/library/math.rst
Outdated
| @@ -192,6 +207,18 @@ Number-theoretic and representation functions | |||
| of *x* and are floats. | |||
|
|
|||
|
|
|||
| .. function:: perm(n, k) | |||
|
|
|||
| Return the number of ways to choose *k* items from *n* items without repetition. | |||
There was a problem hiding this comment.
The "with order" part should be mentioned. Perhaps s/the number/the distinct number/.
FWIW, here is the wording from the itertools docs:
permutations() | p[, r] | r-length tuples, all possible orderings, no repeated elements
combinations() | p, r | r-length tuples, in sorted order, no repeated elements
Modules/mathmodule.c
Outdated
| static PyObject * | ||
| math_comb_impl(PyObject *module, PyObject *n, PyObject *k) | ||
| /*[clinic end generated code: output=bd2cec8d854f3493 input=2f336ac9ec8242f9]*/ | ||
| perm_comb(PyObject *n, PyObject *k, int comb) |
There was a problem hiding this comment.
ISTM that combining the code for comb() and perm() doesn't save us much. I would rather they be decoupled at outset so as to not preclude possible optimizations (there are a number of ways to compute combinations that do early cancellation to keep the intermediate products from exploding in size).
Doc/library/math.rst
Outdated
| @@ -207,6 +207,19 @@ Number-theoretic and representation functions | |||
| of *x* and are floats. | |||
|
|
|||
|
|
|||
| .. function:: perm(n, k) | |||
|
|
|||
| Return the distinct number of ways to choose *k* items from *n* items | |||
There was a problem hiding this comment.
"distinct number of ways" doesn't quite make sense. "number of distinct ways"? Or just lose the "distinct" word altogether.
| @@ -3028,11 +3142,24 @@ math_comb_impl(PyObject *module, PyObject *n, PyObject *k) | |||
| if (n == NULL) { | |||
| return NULL; | |||
| } | |||
| if (!PyLong_CheckExact(n)) { | |||
There was a problem hiding this comment.
I'm looking forward to the day when we can remove this kind of block as unnecessary (perhaps in 3.9). I thought I'd persuaded myself that everything does eventually get converted to plain ints, but now that I look again it's not clear, and I agree that making this check up front is a good idea.
https://bugs.python.org/issue37128