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,FloydWarshallIterator
is 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:
AbstractPathIterator
as supertype to all path iterators (It felt like a very big decision to make theAbstractPathState
or subtypes themselves iterable. I feel that would make sense. What do you think?)FloydWarshallIterator
as a wrapper around theAbstractPathState
. Now, if you want to iterate over all paths, you need to somehow awkwardly wrap your state in aFloydWarshallIterator(state)
.iterate
methods 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_paths
size
,length
andcollect
for this iterator.collect
returns 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_paths
a bit to cut down on allocations in general, but also to make a request for a path with givenstart
anddestination
not do the extra work of calculating all paths fromstart
and then returning only the one todestination
While 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.