diff options
| author | Simon Tatham <anakin@pobox.com> | 2023-02-03 23:12:38 +0000 |
|---|---|---|
| committer | Simon Tatham <anakin@pobox.com> | 2023-02-03 23:22:49 +0000 |
| commit | 517b14e666b0b71fc0bcd5da1b22cdc90d3434c9 (patch) | |
| tree | 8e3270e98031e4cf09388266680cb661bb558ba3 /unfinished | |
| parent | 843d4ca17def11671809786f2a5aebd75f230dd9 (diff) | |
| download | puzzles-517b14e666b0b71fc0bcd5da1b22cdc90d3434c9.zip puzzles-517b14e666b0b71fc0bcd5da1b22cdc90d3434c9.tar.gz puzzles-517b14e666b0b71fc0bcd5da1b22cdc90d3434c9.tar.bz2 puzzles-517b14e666b0b71fc0bcd5da1b22cdc90d3434c9.tar.xz | |
Palisade: replace dfs_dsf() with a simple iteration.
The whole purpose of a dsf is that you can traverse the edges of your
graph in any order you feel like. So if you want to build the
connected components of a graph you can just loop over all the edges
once. There's no need to run a depth-first search.
In fact there were an amazing number of things wrong with this 10-line
function:
- As Ben points out in commit 21193eaf9308ace, it didn't bother with
bounds checking when searching the grid, instead relying on the
never-removed grid boundary to stop the search - which was fragile in
the face of other bugs.
- The recursion uses linear stack, which is much worse than linear
heap, since stacks are often much more limited. (And the dsf _also_
used linear heap.)
- The recursion was completely unnecessary.
- The function used internal knowledge about dsf.c in order to define
the value UNVISITED to match what would happen to work.
- The name 'dfs_dsf' is totally confusing and almost impossible to
type!
Diffstat (limited to 'unfinished')
0 files changed, 0 insertions, 0 deletions