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

"Bug": routing can't find shortest path in every case #16

Open
dominicparga opened this issue Oct 20, 2016 · 5 comments
Open

"Bug": routing can't find shortest path in every case #16

dominicparga opened this issue Oct 20, 2016 · 5 comments
Labels

Comments

@dominicparga
Copy link
Collaborator

Maybe the restrictions are used in a wrong way, so not every shortest path could be found. Max comment on this:

The leaving edges depend on the incoming edge, so if a shortest-path would lead through a certain node from a certain edge that enables different outgoing edges than the evaluation of said node before, and such an outgoing edge is only accessible from the incoming edge used at the second evaluation, the algorithm would not provide a correct answer, because the node will not be evaluated two (or more) times.
The correct behaviour could be restored by storing visited nodes in combination with outgoing edges.

@dominicparga dominicparga added this to the Routing: optimization without new algorithms milestone Oct 20, 2016
@dominicparga dominicparga self-assigned this Oct 20, 2016
@dominicparga
Copy link
Collaborator Author

We agree on accepting this bug for better performance, because we think the problematic situation occurs seldom or never.

@dominicparga dominicparga changed the title Maybe bug: routing can't find shortest path in every case "Bug": routing can't find shortest path in every case Nov 20, 2016
@dominicparga
Copy link
Collaborator Author

We should check the performance under following settings: we allow pushing visited nodes into the priority queue.

Possible problems:

  • very less performance because too many unused instances are in the queue.
  • memory usage in large graphs (e.g. Tokyo, Peking or Baden-Württemberg in South-West-Germany)?

@dominicparga dominicparga reopened this Nov 20, 2016
@dominicparga dominicparga removed this from the Routing: optimization without new algorithms milestone Feb 5, 2017
@dominicparga
Copy link
Collaborator Author

dominicparga commented Feb 27, 2017

I've implemented a data structure providing following functionality:

  • It can store objects using a comparator or the objects' natural order. This is implemented using a skip list, because its runtime complexity for all basic operations is in O(logn) (expected with high probability) in contrast to Java's PriorityQueue in O(n) for remove. In addition to get(Object) in O(logn), our skip list implementation provides get(index)in O(logn).
  • It can detect duplicates by their hashcodes. If an object with equal hashcode is in the priority queue, the old value is replaced by the new one (with new priority) in O(logn).

With this data structure, the storage is in O(n) with no duplicates where n is equal to the number of nodes. The performance and storage should be checked if object means the tuple (node, incoming edge).

@dominicparga
Copy link
Collaborator Author

Edit to skip list: Access time in comparison to Java's priority queue is doubled, so the skip list is too slow.

@dominicparga
Copy link
Collaborator Author

Possible approximation:
Now, every node is visited once, because the algorithm doesn't terminate with infinite visits per node. We could count the visits and set the bound to 2 or 3 instead of 1.

@dominicparga dominicparga removed their assignment Jan 19, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant