This repository has been archived by the owner on Oct 8, 2021. It is now read-only.
Have added Wilson's algorithm and loop erased random walks #1576
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.
In reference to issue #1571 I have updated LightGraphs with (i) an implementation of Wilson's algorithm, and (ii) an implementation of a loop erased random walk (used by Wilson's algorithm). Both methods have been incorporated into the unit tests. All of the code I have included only calls from the standard library.
For Wilson's, I have implemented the algorithm on a small graph with an easy-to-compute answer, generated a collection of random spanning trees, and then tested that the Monte Carlo scheme was within a tolerance of the exact answer. I repeated this process on a weighted graph. For the loop erased random walks, I have mimicked the tests in traversals/randomwalks (to the extent that it made sense; there are some modifications).
I have mostly kept the code structure the same as the source. There is one small exception, in that I have allowed a user to pass an AbstractRNG as there have been notable deficiencies in the Mersenne Twister although I have performed tests only with this RGN (and found no issues).
In terms of memory use, and with regards to the loop erased random walk, I have attempted to strike a balance between allocation frequency and memory consumption. I have elected to use views as the loop erased random walk may frequently shorten in length and I didn't want to deallocate memory only to immediately reclaim it. This made it natural me to forego using push. When a walk hits the current memory limits, the size of the existing vector is set to the minimum between the doubled length and the number of vertices in the graph. If the maintainers prefer, I am fine to move back to a push!/shorten framework.