Since I first added it, I've found I've needed to extend delta debugging's capabilities.
Zeroth, I added the logical inverse of Star.parse_line_into_star to take an existing Star object and convert it to a canonical string. Obvious functional round trip is obvious.
First, I pulled each existing pass (sector, subsector, single-line, two-line) into a class in the DeltaPasses folder, to ease the main task of adding more passes. The basic idea is now that a delta run calls one or more passes, defined by command line options.
Second, I added a DeltaStar subclass of Star that applies some combination of twelve separate, mutually orthogonal, reductions to a given star line:
Drop route segments
Drop noble codes
Drop base codes
Drop Amber/Red trade zones
Drop extra stars beyond primary
Reset PBG to 100
Reduce extra worlds in system to 1
Set port to C class
Set TL to 8
Drop sophont codes (population, homeworld, dieback, etc)
Drop capital codes
Drop remaining trade codes
Third, I added a reduce by allegiance pass - seeing if removing all stars with (one of a set of) allegiances makes for an interesting result.
Fourth, I used the DeltaStar-powered reductions to add a set of within-line reduction passes:
All listed within-line reductions
Reduce importance (drop trade codes, drop base codes, reset port, reset TL)
Reduce auxiliary characteristics (drop routes, drop noble codes, drop trade zone, drop extra stars, reset PBG, reset worlds, drop sophont codes)
Drop capital codes (split out separately from importance reduction due to the specific effect capitals have)
Each within-line pass is applied to as many lines as possible in the remaining input if the current within-line pass changes the given line. As a result, lines that successfully receive all-reductions are skipped for the later within-line passes, since their current status already has the later reductions applied.
The within-line passes are collected and applied as a meta-pass after line reduction.
Fifthly, I added a more MacIverian capability to single-line reduction, and have called it "widen-breach." For example, say there's 200 lines remaining over 5 chunks. Chunk # 4 is removed, sending lines 121-160, inclusive, out the window.
Using the original line numbers, widen-breach tries to remove first line 120, then lines 118-119, then lines 114-117, etc, iteratively doubling the number of lines to remove, until removal fails. In cases where widen-breach can't make any progress, it incurs just the single removal attempt and moves on. Where it can, it pushes as hard as possible.
I'm still arguing with myself about whether to add widen-breach in the forward direction. Reverse widen-breach is intended to chip away at some part of a previously-retained block, while lines in the forwards direction could still be dropped out en chunk.
As always, @tjoneslo , please review and point out where this work can be improved.
Since I first added it, I've found I've needed to extend delta debugging's capabilities.
Zeroth, I added the logical inverse of
Star.parse_line_into_star
to take an existing Star object and convert it to a canonical string. Obvious functional round trip is obvious.First, I pulled each existing pass (sector, subsector, single-line, two-line) into a class in the
DeltaPasses
folder, to ease the main task of adding more passes. The basic idea is now that a delta run calls one or more passes, defined by command line options.Second, I added a DeltaStar subclass of Star that applies some combination of twelve separate, mutually orthogonal, reductions to a given star line:
Third, I added a reduce by allegiance pass - seeing if removing all stars with (one of a set of) allegiances makes for an interesting result.
Fourth, I used the DeltaStar-powered reductions to add a set of within-line reduction passes:
Each within-line pass is applied to as many lines as possible in the remaining input if the current within-line pass changes the given line. As a result, lines that successfully receive all-reductions are skipped for the later within-line passes, since their current status already has the later reductions applied. The within-line passes are collected and applied as a meta-pass after line reduction.
Fifthly, I added a more MacIverian capability to single-line reduction, and have called it "widen-breach." For example, say there's 200 lines remaining over 5 chunks. Chunk # 4 is removed, sending lines 121-160, inclusive, out the window.
Using the original line numbers, widen-breach tries to remove first line 120, then lines 118-119, then lines 114-117, etc, iteratively doubling the number of lines to remove, until removal fails. In cases where widen-breach can't make any progress, it incurs just the single removal attempt and moves on. Where it can, it pushes as hard as possible.
I'm still arguing with myself about whether to add widen-breach in the forward direction. Reverse widen-breach is intended to chip away at some part of a previously-retained block, while lines in the forwards direction could still be dropped out en chunk.
As always, @tjoneslo , please review and point out where this work can be improved.