BasicBidirectionalActions only works for environment with simple actions

[ctjoreilly]

This will only work in environments like Map2D where the actions are simply Go from 1 node to the next. i.e. all nodes connected to a target node would have the same action, go to the target node. This lets you, as is currently done, to create the lists from and start to goal and the reverse by joining the lists appropriately. However, in the case of more complex environments/actions this will not work. For example, if you are in a grid and the actions are left, right, up, down and say you start at the top and bottom and meet in the middle the actions would be something like:

start->meet at = down, down
goal->meet at = up up

Joining these in the current manner would not work.

@Manthan-R-Sheth can you look into.

[Manthan-R-Sheth]

I get your point and according to me, for considering such cases, some additional information about the actions needs to be known. Like in your case, information about opposing actions (up and down). So there will be a need for extending the API, right? Like information about opposing actions for example, so that the lists can be joined appropriately.

[ctjoreilly]

It looks like you'll need access to the nodes from each direction and the problem (i.e. Actions and ResultFunction and possibly the StepCostFunction) to properly construct the actions in both directions.

[Manthan-R-Sheth]

@ctjoreilly I was wondering if this could be done?
After the meetingNode is found, a search algorithm can be used (say BreadthFirstSearch) two times (one for the path from meetingNode to initialState and other for the path from meetingNode to goalState). These two results in addition to fromInitialStatePart() and fromFinalStatePart() can be used to make the 4 lists appropriately.

[Manthan-R-Sheth]

Also, should I add the checks for null (now that the API structure is agreed to be kept as is) so that null doesn't appear as a part of the resulting list?
This will handle Todo test case in the BidirectionalSearchTest.

[ctjoreilly]

I don't think using say BreadthFirstSearch two times to figure out the reverse actions from each direction makes sense (it would kind of defeat the purpose). As you should know the nodes its only a matter of determining which action to connect to the next known node in reverse. You can use the cost (if available) to select the min action if more than one moves you to the next target node. As regards the checks I believe an update to this pull request:

#297

which is being worked on by @globalworming should address it. This issue is separate.

[Manthan-R-Sheth]

Ya i understand that the issue is separate, bu I though to handle the checks myself. Nevertheless let @globalworming do that fix up, meanwhile I have added support for complex actions. #304

[ctjoreilly]

I am going to close this issue instead the implementations of BidirectionalSearch should handle this correctly by setting up BidirectionalSearchResult correctly (i.e. the basic implementation of this interface should remain trivial). I am going to setup a separate issue stating the BidirectionalSearchTest should be extended to include more complex environments so that this can be verified.