Fixes in sorting descriptions (GH-18317)

Improvements in listsort.txt and a comment in sortperf.py.

Automerge-Triggered-By: @csabella
This commit is contained in:
Stefan Pochmann 2020-02-03 17:47:20 +01:00 committed by GitHub
parent 4b524161a0
commit 24e5ad4689
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
2 changed files with 9 additions and 9 deletions

View File

@ -134,7 +134,7 @@ def tabulate(r):
L = list(range(half - 1, -1, -1)) L = list(range(half - 1, -1, -1))
L.extend(range(half)) L.extend(range(half))
# Force to float, so that the timings are comparable. This is # Force to float, so that the timings are comparable. This is
# significantly faster if we leave tham as ints. # significantly faster if we leave them as ints.
L = list(map(float, L)) L = list(map(float, L))
doit(L) # !sort doit(L) # !sort
print() print()

View File

@ -319,13 +319,13 @@ So merging is always done on two consecutive runs at a time, and in-place,
although this may require some temp memory (more on that later). although this may require some temp memory (more on that later).
When a run is identified, its base address and length are pushed on a stack When a run is identified, its base address and length are pushed on a stack
in the MergeState struct. merge_collapse() is then called to see whether it in the MergeState struct. merge_collapse() is then called to potentially
should merge it with preceding run(s). We would like to delay merging as merge runs on that stack. We would like to delay merging as long as possible
long as possible in order to exploit patterns that may come up later, but we in order to exploit patterns that may come up later, but we like even more to
like even more to do merging as soon as possible to exploit that the run just do merging as soon as possible to exploit that the run just found is still
found is still high in the memory hierarchy. We also can't delay merging high in the memory hierarchy. We also can't delay merging "too long" because
"too long" because it consumes memory to remember the runs that are still it consumes memory to remember the runs that are still unmerged, and the
unmerged, and the stack has a fixed size. stack has a fixed size.
What turned out to be a good compromise maintains two invariants on the What turned out to be a good compromise maintains two invariants on the
stack entries, where A, B and C are the lengths of the three rightmost not-yet stack entries, where A, B and C are the lengths of the three rightmost not-yet
@ -739,7 +739,7 @@ slice (leaving off both endpoints) (2**(k-1)-1)+1 through (2**k-1)-1
inclusive = 2**(k-1) through (2**k-1)-1 inclusive, which has inclusive = 2**(k-1) through (2**k-1)-1 inclusive, which has
(2**k-1)-1 - 2**(k-1) + 1 = (2**k-1)-1 - 2**(k-1) + 1 =
2**k-1 - 2**(k-1) = 2**k-1 - 2**(k-1) =
2*2**k-1 - 2**(k-1) = 2*2**(k-1)-1 - 2**(k-1) =
(2-1)*2**(k-1) - 1 = (2-1)*2**(k-1) - 1 =
2**(k-1) - 1 2**(k-1) - 1
elements. elements.