This issue tracker has been migrated to GitHub ,
and is currently read-only.
For more information,
see the GitHub FAQs in the Python's Developer Guide.
Created on 2013年05月07日 21:38 by tim.peters, last changed 2022年04月11日 14:57 by admin. This issue is now closed.
| Messages (5) | |||
|---|---|---|---|
| msg188686 - (view) | Author: Tim Peters (tim.peters) * (Python committer) | Date: 2013年05月07日 21:38 | |
Each time thru, CWR searches for the rightmost position not containing the maximum index. But this is wholly determined by what happened the last time thru - search isn't really needed. Here's Python code: def cwr2(iterable, r): pool = tuple(iterable) n = len(pool) if not n and r: return indices = [0] * r yield tuple(pool[i] for i in indices) j = r-1 if n > 1 else -1 while j >= 0: newval = indices[j] + 1 indices[j:] = [newval] * (r - j) yield tuple(pool[i] for i in indices) j = r-1 if newval < n-1 else j-1 There `j` is the rightmost position not containing the maximum index. A little thought suffices to see that the next j is either r-1 (if newval is not the maximum index) or j-1 (if newval is the maximum index: since the indices vector is non-decreasing, if indices[j] was r-2 then indices[j-1] is also at most r-2). I don't much care if this goes in, but Raymond should find it amusing so assigning it to him ;-) |
|||
| msg188687 - (view) | Author: Tim Peters (tim.peters) * (Python committer) | Date: 2013年05月07日 21:41 | |
Oops! Last part should read "since the indices vector is non-decreasing, if indices[j] was n-2 then indices[j-1] is also at most n-2" That is, the instances of "r-2" in the original should have been "n-2". |
|||
| msg188735 - (view) | Author: Tim Peters (tim.peters) * (Python committer) | Date: 2013年05月08日 20:48 | |
There's another savings to be had when an index becomes the maximum: in that case, all the indices to its right are already at the maximum, so no need to overwrite them. This isn't as big a savings as skipping the search, but still buys about 10% more in the Python code. Like so: def cwr3(iterable, r): pool = tuple(iterable) n = len(pool) if n == 0 and r: return indices = [0] * r yield tuple(pool[i] for i in indices) rmax, nmax = r-1, n-1 j = rmax if n > 1 else -1 while j >= 0: newval = indices[j] + 1 if newval < nmax: indices[j:] = [newval] * (r - j) j = rmax else: assert newval == nmax indices[j] = newval j -= 1 yield tuple(pool[i] for i in indices) |
|||
| msg188897 - (view) | Author: Raymond Hettinger (rhettinger) * (Python committer) | Date: 2013年05月11日 06:51 | |
Thanks Tim :-) |
|||
| msg196815 - (view) | Author: Tim Peters (tim.peters) * (Python committer) | Date: 2013年09月02日 21:57 | |
I'm closing this. While it makes a big difference for a cwr coded in Python, it turn out to be minor in C. The extra complications (more state to remember and update across next() invocations) isn't worth the minor speedup in C. |
|||
| History | |||
|---|---|---|---|
| Date | User | Action | Args |
| 2022年04月11日 14:57:45 | admin | set | github: 62130 |
| 2013年09月02日 21:57:11 | tim.peters | set | status: open -> closed resolution: rejected messages: + msg196815 stage: needs patch -> resolved |
| 2013年08月15日 22:17:00 | pitrou | set | nosy:
+ serhiy.storchaka |
| 2013年05月11日 06:51:28 | rhettinger | set | messages: + msg188897 |
| 2013年05月10日 19:29:25 | terry.reedy | set | nosy:
+ terry.reedy |
| 2013年05月08日 20:48:20 | tim.peters | set | messages: + msg188735 |
| 2013年05月07日 21:41:49 | tim.peters | set | messages: + msg188687 |
| 2013年05月07日 21:38:43 | tim.peters | create | |