[WIP] Iterators for path states #221
Draft
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.
As indicated in issue #217, I started working on an
AbstractPathIterator, to loop over all paths encoded in anAbstractPathState. Currently, only one subtype,FloydWarshallIteratoris implemented and tested. I would very much like your feedback on the approach taken here, so that I can start implementing something similar for the otherPathStates, if possible.Here is a short list of the thinks I have done:
AbstractPathIteratoras supertype to all path iterators (It felt like a very big decision to make theAbstractPathStateor subtypes themselves iterable. I feel that would make sense. What do you think?)FloydWarshallIteratoras a wrapper around theAbstractPathState. Now, if you want to iterate over all paths, you need to somehow awkwardly wrap your state in aFloydWarshallIterator(state).iteratemethods needed for iterationenumerate_path_into!method, which writes a path into a pre-allocated array and returns a view, dramatically cutting down on allocations, compared toenumerate_pathssize,lengthandcollectfor this iterator.collectreturns a matrix that works in the same way as the matrices in the state, that is, matrix[s,d] is the path from s to d. (this feels more logical, than the current output fromenumerate_paths)enumerate_pathsa bit to cut down on allocations in general, but also to make a request for a path with givenstartanddestinationnot do the extra work of calculating all paths fromstartand then returning only the one todestinationWhile I am happy with the changes to
enumerate_paths, I would very much like your feedback on the decisions I took with the iterator part.