Closed eriknw closed 1 year ago
Base: 72.25% // Head: 69.57% // Decreases project coverage by -2.69%
:warning:
Coverage data is based on head (
9388982
) compared to base (6dd93bd
). Patch coverage: 32.03% of modified lines in pull request are covered.
:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more
:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.
I wonder how we can/should optimize for undirected graphs (i.e., symmetric adjacency matrix). Perhaps we can only compute the lower or upper triangular portion of the results while iterating.
Implemented (via upper triangles)! This wasn't too hard or invasive to do, but it does make the implementation a little more complicated. We still symmetrize the results at the end--maybe someday we'll be able to avoid this step.
This follows up on #42 to also compute predecessors with floyd_warshall.
CC @jim22k @SultanOrazbayev @LuisFelipeRamos
I came up with the algorithm for computing predecessors via trial and error--i.e., a lot of guessing :). The outcome seems reasonable/plausible, and it passes tests.
As the comments indicate, by adding the use of
Mask
, we increase memory usage, but it computes faster. I don't have a great feel for when we should trade memory for speed or vice versa. So, let's go with the simple option, which happens to be the faster option.Also, instead of converting the output Matrix to a dict of dicts, I convert it to a new object
NodeNodeMap
that behaves similarly and is backed by the matrix. I updated other uses offill_value
withNodeMap
to keep the output sparse (i.e., don't fill withfill_value
).I wonder how we can/should optimize for undirected graphs (i.e., symmetric adjacency matrix). Perhaps we can only compute the lower or upper triangular portion of the results while iterating.
Our original
floyd_warshall
was nice, because it looked a lot more like a typical floyd-warshall implementation. The new version that can also compute predecessors is nice b/c it's more capable without duplicating a bunch of code, but less nice b/c it's more complicated. Please let me know if anything infloyd_warshall_predecessor_and_distance
can be more clear.