Search: Bidirectional Search #554
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
dj5x5
pushed a commit
to dj5x5/aima-python
that referenced
this pull request
Jul 17, 2025
* Add bidirectional search + update h function * add bidirectional search test
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
I implemented the Bidirectional Search algorithm from this paper: https://webdocs.cs.ualberta.ca/%7Eholte/Publications/MM-AAAI2016.pdf
Even though we don't have AIMA pseudocode for the algorithm, I think it is OK to implement the algorithm and update it later. I left a note in the implementation to let people know where the code comes from.
Also, in the book, Bidirectional Search is classified under "Uninformed Search", while in the pseudocode it makes use of a heuristic function. In the module I classified it under a new "chapter", simply named "Bidirectional Search". I can change it if it is not appropriate.
In the pseudocode we have a lot of side-functionality (finding mins, finding keys etc.) which I implemented as closures (functions-inside-function). I believe it is the best, at least for now, to keep it all packed together since we don't have the final pseudocode yet.
In the
GraphProblemfunctionh(which finds the real-world distance between nodes) we only take as input nodes, but I found that a bit limiting. In this algorithm's case it makes more sense to store node names instead, so I updatehto take as input strings too. The code for it, in my opinion, is a bit ugly so although it works I welcome any feedback to improve on it.Finally, I added a test for the algorithm. Unfortunately the pseudocode returns only the path cost and not the nodes on the path. I think it would be great if in the final pseudocode we could store the path itself to be consistent with the rest of the algorithms.