Skip to content

Commit 3041d97

Browse files
committed
Only some formatting edits to keep consistency between sort_index and ord_sort
1 parent 0077952 commit 3041d97

File tree

2 files changed

+20
-21
lines changed

2 files changed

+20
-21
lines changed

Diff for: src/stdlib_sorting_ord_sort.fypp

+2-2
Original file line numberDiff line numberDiff line change
@@ -118,9 +118,9 @@ contains
118118

119119
array_size = size( array, kind=int_index )
120120
if ( present(work) ) then
121-
if ( size( work, kind=int_index) < array_size/2 ) then
121+
if ( size(work, kind=int_index) < array_size/2 ) then
122122
error stop "${name1}$_${sname}$_ord_sort: work array is too small."
123-
endif
123+
end if
124124
! Use the work array as scratch memory
125125
call merge_sort( array, work )
126126
else

Diff for: src/stdlib_sorting_sort_index.fypp

+18-19
Original file line numberDiff line numberDiff line change
@@ -80,31 +80,32 @@ contains
8080
! a non-increasing sort. The logic of the determination of indexing largely
8181
! follows the `"Rust" sort` found in `slice.rs`:
8282
! https://github.com/rust-lang/rust/blob/90eb44a5897c39e3dff9c7e48e3973671dcd9496/src/liballoc/slice.rs#L2159
83-
! The Rust version is a simplification of the Timsort algorithm described
84-
! in https://svn.python.org/projects/python/trunk/Objects/listsort.txt, as
83+
! The Rust version in turn is a simplification of the Timsort algorithm
84+
! described in
85+
! https://svn.python.org/projects/python/trunk/Objects/listsort.txt, as
8586
! it drops both the use of 'galloping' to identify bounds of regions to be
8687
! sorted and the estimation of the optimal `run size`. However it remains
8788
! a hybrid sorting algorithm combining an iterative Merge sort controlled
8889
! by a stack of `RUNS` identified by regions of uniformly decreasing or
89-
! non-decreasing sequences that may be expanded to a minimum run size, with
90-
! an insertion sort.
90+
! non-decreasing sequences that may be expanded to a minimum run size and
91+
! initially processed by an insertion sort.
9192
!
9293
! Note the Fortran implementation simplifies the logic as it only has to
9394
! deal with Fortran arrays of intrinsic types and not the full generality
9495
! of Rust's arrays and lists for arbitrary types. It also adds the
9596
! estimation of the optimal `run size` as suggested in Tim Peters'
96-
! original listsort.txt, and the optional `work` and `iwork` arrays to be
97+
! original `listsort.txt`, and the optional `work` and `iwork` arrays to be
9798
! used as scratch memory.
9899

99-
${t1}$, intent(inout) :: array(0:)
100+
${t1}$, intent(inout) :: array(0:)
100101
${ti}$, intent(out) :: index(0:)
101-
${t3}$, intent(out), optional :: work(0:)
102+
${t3}$, intent(out), optional :: work(0:)
102103
${ti}$, intent(out), optional :: iwork(0:)
103-
logical, intent(in), optional :: reverse
104+
logical, intent(in), optional :: reverse
104105

105-
integer(int_index) :: array_size, i, stat
106106
${t2}$, allocatable :: buf(:)
107107
${ti}$, allocatable :: ibuf(:)
108+
integer(int_index) :: array_size, i, stat
108109

109110
array_size = size(array, kind=int_index)
110111

@@ -189,7 +190,7 @@ contains
189190
pure subroutine insertion_sort( array, index )
190191
! Sorts `ARRAY` using an insertion sort, while maintaining consistency in
191192
! location of the indices in `INDEX` to the elements of `ARRAY`.
192-
${t1}$, intent(inout) :: array(0:)
193+
${t1}$, intent(inout) :: array(0:)
193194
${ti}$, intent(inout) :: index(0:)
194195

195196
integer(int_index) :: i, j
@@ -219,7 +220,6 @@ contains
219220
!
220221
! 1. len(-3) > len(-2) + len(-1)
221222
! 2. len(-2) > len(-1)
222-
223223
integer(int_index) :: r
224224
type(run_type), intent(in), target :: runs(0:)
225225

@@ -274,7 +274,7 @@ contains
274274
! Consistency of the indices in `index` with the elements of `array`
275275
! are maintained.
276276

277-
${t1}$, intent(inout) :: array(0:)
277+
${t1}$, intent(inout) :: array(0:)
278278
${ti}$, intent(inout) :: index(0:)
279279

280280
${t3}$ :: tmp
@@ -315,9 +315,9 @@ contains
315315
! worst-case. Consistency of the indices in `index` with the elements of
316316
! `array` are maintained.
317317

318-
${t1}$, intent(inout) :: array(0:)
318+
${t1}$, intent(inout) :: array(0:)
319319
${ti}$, intent(inout) :: index(0:)
320-
${t3}$, intent(inout) :: buf(0:)
320+
${t3}$, intent(inout) :: buf(0:)
321321
${ti}$, intent(inout) :: ibuf(0:)
322322

323323
integer(int_index) :: array_size, finish, min_run, r, r_count, &
@@ -335,7 +335,6 @@ contains
335335
return
336336
end if
337337

338-
339338
! Following Rust sort, natural runs in `array` are identified by traversing
340339
! it backwards. By traversing it backward, merges more often go in the
341340
! opposite direction (forwards). According to developers of Rust sort,
@@ -385,7 +384,7 @@ contains
385384
left = runs( r + 1 )
386385
right = runs( r )
387386
call merge( array( left % base: &
388-
right % base + right % len - 1 ), &
387+
right % base + right % len - 1 ), &
389388
left % len, buf, &
390389
index( left % base: &
391390
right % base + right % len - 1 ), ibuf )
@@ -408,9 +407,9 @@ contains
408407
! using `BUF` as temporary storage, and stores the merged runs into
409408
! `ARRAY(0:)`. `MID` must be > 0, and < `SIZE(ARRAY)-1`. Buffer `BUF`
410409
! must be long enough to hold the shorter of the two runs.
411-
${t1}$, intent(inout) :: array(0:)
412-
integer(int_index), intent(in) :: mid
413-
${t3}$, intent(inout) :: buf(0:)
410+
${t1}$, intent(inout) :: array(0:)
411+
integer(int_index), intent(in) :: mid
412+
${t3}$, intent(inout) :: buf(0:)
414413
${ti}$, intent(inout) :: index(0:)
415414
${ti}$, intent(inout) :: ibuf(0:)
416415

0 commit comments

Comments
 (0)