graph/coloring: allow warm start for DsaturExact #1764
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
There is an optimisation that is available for the Dsatur recursive search that takes advantage of the trivial observation that the colouring of a maximum clique in the graph must be consistent with the colouring of the graph and that a maximum clique will therefore constrain the colouring of the graph. This means that if the maximum clique is first trivially coloured the search can continue from there. However, if there are multiple co-equal maximum cliques it is possible for a clique to be chosen that will force the search down a pessimal search path, so we choose the clique to start from as the clique with the least constraining effect on the rest of the graph. The optimisation has the effect of excluding large sections of the search tree with a small amount of initial work to assess the maximum cliques. This change chooses the maximum clique with the lowest degree into the rest of the graph and assigns colours to all its nodes and progresses from there.
Codecov Report
@@ Coverage Diff @@
## master #1764 +/- ##
=======================================
Coverage 73.36% 73.37%
=======================================
Files 520 520
Lines 61341 61361 +20
=======================================
+ Hits 45003 45021 +18
- Misses 13803 13806 +3
+ Partials 2535 2534 -1
Continue to review full report at Codecov.
|
vladimir-ch
approved these changes
Jan 20, 2022
|
Here are the benchmarks. It looks horrifying until you look at the larger queens cases, and the sudoku problem. The variance on the times is very high due to the high impact of search path that is chosen, and the fact that it is partially randomly chosen.
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Almost all the other benchmarks are in the order of (tens of) µs, so I would put more weight on the larger problems where the warm up pays off. Are there other (generated) larger benchmark problems that we could add? |
|
There are a bunch from where I got the queens graphs. Note that queens-8-8 takes a very long time with this implementation (either old or new) due to allocation inefficiency that I want to fix. I'm not particular fussed to add more bench marks. I think the result is sound. |
|
Agreed. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is a replay of #1705, now onto the merged coloring package. I had originally intended to wait until I had improved the base performance of the
DsaturExactimplementation before I applied this change, but I suspect that I won't have time to address that for a while (my initial investigations suggest that it's both subtle and extensive to improve the way that the color accounting is currently done), so rather than wait with a poorly performing exact coloring implementation I think this should go in, and the work to formally examine the impact of this change can happen after the base improvements are made with minor alterations of code added here.The algorithmic addition is quite straightforward and I think the implications on run time are reasonably clear. I have some rough notes that I prepared a while back that I can make available to explain the behaviour (OOB since they are not public quality yet).
Please take a look.