Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Speed up dists and flow aggregation #69

Closed
mpadge opened this issue Oct 24, 2018 · 1 comment
Closed

Speed up dists and flow aggregation #69

mpadge opened this issue Oct 24, 2018 · 1 comment
Labels
enhancement New feature or request

Comments

@mpadge
Copy link
Member

mpadge commented Oct 24, 2018

Instead of calculating paths between all pairs of input vertices, each iteration could store all IDs of vertex pairs along all previously-traced paths. A new Dijkstra would then need only be run if the start and end vertices did not appear in this list. This would effectively be equivalent to implementing the Floyd-Warshall algorithm.

Extra efficiency could likely be gained by first calculating straight-line distances between all vertices (where possible, which may not always be the case), and running Dijkstra's on the vertex pairs as sorted in order of decreasing distance. Because distances would be calculated from each from vertex to all other vertices, these distances could be calculated as maximal pair-wise distances from each from vertex to all nominated to vertices.

The ultimate aim here would be to speed up flow aggregation, which is currently pretty slow compared, for example, to igraph::betweenness().

@mpadge mpadge added the enhancement New feature or request label Oct 24, 2018
@mpadge mpadge added this to TODO v0.3.0 in version 0.2-0.3 Oct 24, 2018
@mpadge mpadge moved this from TODO v0.3.0 to TODO v0.2.0 in version 0.2-0.3 Apr 5, 2019
@mpadge
Copy link
Member Author

mpadge commented May 10, 2019

Actually, a better way to speed up flow aggregation will be to have no edge properties at all, and just calculate paths, then re-trace them and add the flows along each segment. The actual dijkstra stage would then be <int>-based, with uniform values of 1, and so would be much quicker. This should be done. Nah, that's not right at all; paths still have to be traced with weighted distances, so this can't really be done efficiently after all (not in any general way at least).

@mpadge mpadge closed this as completed May 13, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant