I've been given a homework in Java, where I have to write an algorithm.
I have to find the path between two vertices, through the highest possible point (like a geographic point, with the height from the water surface). I have to use BFS.
So therefore I would like to ask if someone could point me in the right direction. I've been digging through the internet for a while now and I can't seem to find anything that could help me with my problem.
The code I've been given to modify and add methods is here .
Thank you.
As it can be seen, your path from A to B through H (the highest vertix) can be splitted into 2 paths: from A to H, and from H to B. Then BFS can be used for these 2 paths separately.
It is more interesting if there are several vertices H with the same value of 'height' crtireium. It is subject to think whether there is something better than simple looking through all options.
Related
If I have a list of points returned from a breadth-first-search through a type of 2D array maze in Java, how could I find the shortest path in that list of points?
For example, if my potential target points are [2, 4] and [6, 0] and I have a list of points that goes to each target point, how can I find out which route is shortest?
I'm thinking I might have to use Djikstra's Algorithm or something, but I'm unsure.
Thanks very much
You can use Dijkstra's algorithm here. Given the array maze you mentioned, the first step would be to get all the edges in your maze between 2 adjacent nodes, and the edge costs. For the nodes, you would need to know if each node has been visited, and the current cost of visiting that node.
Now, if you are not concerned with getting the shortest path, you might not need Dijkstra's. Instead, you can use a DP/Recursion approach to get possible paths from a source coordinate to a target coordinate. If you want to see a Dijkstra's implementation, this is something I had written. To get the shortest path, you would obviously need the distance between nodes.
To just find a path between 2 points, I would suggest something like this implementation. It includes both DP and recursion implementations and compares the running times for both (recursion can take very long to run for large datasets).
I feel this much should be enough to get you started. Let me know if you need some other information.
I didn't end up using Dijkstra's, but instead changed my breadth-first-search to add a "level" value or "distance" value from the origin point that would count upward with each visited node. The counts would stay consistent if the path ever branched, and since I already knew the end point, all it would take is to check out what the "count" was in my end points and compare.
Thank you for your help though! You'll get an upvote if the site lets me.
For those facing a similar problem:
I made a simple class called PointC which inherits from Point, but with an added "count" value. The count was updated appropriately with each step of the breadth first search, then the end points were compared at the end to obtain the most optimal path.
I know, this is an old problem, if given a matrix like：
[1 1 2 3，
2 3 4 4，
3 4 1 3，
2 1 3 4]
Start at a given position, from right to left, only move right or up or down, can not go back in same way and stop at right, find a path to get max value.
I am considering to use DP(May need try all possible path and calculate value), but it seems it will cost a lot of memory since it store all the possible solutions and may also be slow.
I am wondering if there are any other thoughts or ways to make a better solution? A quicker solution if possible?
I think that there is a way to do a DP and I just can't quickly find it. Because no one answered it so far I will give a graph method. Create a directed graph where an edge from A to B will be equal to the number in that vertex. It is clear from your description that it will not have any cycles. You will get a grid graph like this, but only directed:
Now get an vertex source which is somewhere on the right and connect it to the first layer (put all the edges equal to 0). The same with a destination, but it is on the left.
Now run longest path in directed acyclic graph
If you want to optimize for memory, you might try Backtracking. This would involve only storing the current path, and the path and value for the best solution yet.
Outline is:
You store a list of steps (right, up, down)
You go depth-first so to speak, try to make a new step if you can
If you can't, just go back one and change the step to the next possible direction. (Store this path if it's better than previously stored one).
If there is no next possible direction for the step, repeat 3.
If all possibilities are exhausted, return the stored best path.
Backtracking at wikipedia: https://en.wikipedia.org/wiki/Backtracking
I am currently working on a project involving a mixture of travelling salesman and shortest path. It goes as follows:
I am given a set of 9 vertices,all with positive coordinates in 2 space, (x,y), where x and y are positive real numbers. I am then asked to compute the shortest path a travelling salesman can take, and traverse through all the points. In essence, the graph is simply a collection of nodes with coordinates, and I have to arrange the edges, such that there is a connection from node 1 to node 9, that is the shortest possible one. It is assumed that I have already visited at the beginning node 1 (x1,y1), and need to visit each node once and only once. I will end on node 9, specified by (x9,y9).
I am writing the program in Java, although the professor said that the program can be written in any language.
I started by writing a node class, which represents each node, and has fields x,y which represent the x and y coordinates respectively. However, I am completely stumped as to how to perform the optimization.
I would greatly appreciate any assistance with respect to this problem.
Thank you very much, and I am excited to become a member of this community!
Euclidean TSP remains NP-hard, so just go for whatever algorithm for general TSP you want; for 9 vertices, the brute force solution compares 7! = 5040 permutations of the 7 intermediate vertices (since you start at 1 and end in 9 as per the problem description), so all you would need to do for that is generate all permutations of {2,...,8} and then just check the length of those paths.
If you want something slightly fancy, go for the dynamic programming approach by Held, Karp and separately Bellman which you can read up on in lots of places online, so I won't be posting how that works.
Is there an algorithm that can tell you what points to connect to form a triangle given a set of points? None of the connecting lines can intersect, however triangles can be inside of other triangles.
Given a general set of points in R^d the Delaunay triangulation is often an optimal choice for tessellation.
Specifically, the Delaunay triangulation will tessellate the convex hull of the point set into a set of non-overlapping elements, ensuring that the radius of the largest circumsphere is minimised - this means that the triangulation is optimal in terms of its "compactness", or in other words, elements with good aspect ratio are generated.
Efficient algorithms to construct Delaunay triangulations are not trivial, but there are a number of good libraries out there - I can recommend Triangle, CGAL or Qhull (for high dimensional problems) also JDT is apparently an implementation in Java, though I've never used it.
I am not sure it is exactly what you are looking for, but it may be of some help: Graph Theory
I am also attempting to solve this problem. This is a link to the github branch of someone who works on this for the game Ingress, which is why I'm interested in the solution. However, to my knowledge the optimal solution is found through brute force (I may be wrong on this), and has other factors it maximizes and minimizes. Also I think there are things such as taking in an E6 latitude/longitude and projects onto a Gnomonic projection to determine shortest routes, however I think this can be discounted when going through the code. I don't think there is your solution in this code, but it might be a good jumping off point for you, me, and anyone else looking into this problem.
What would be the best algorithm in terms of speed for locating an object in a field?
The field consists of 18 by 18 squares with side length 30.48 cm. The robot is placed in the square (0,0) and its job is to reach the light source while avoiding obstacles along the way. To locate the light source, the robot does a 360 degree turn to find the angle with the highest light reading and then travels towards the source. It can reliably detect a light source from 100 cm.
The way I'm implementing this presently is I'm storing the information about each tile in a 2x2 array. The possible values of the tiles are unexplored (default), blocked (there's an obstacle), empty (there's nothing in there). I'm thinking of using the DFS algorithm where the children are at position (i+3,j) or (i,j+3). However, considering the fact that I will be doing a rotation to locate the angle with the highest light reading at each child, I think there may be an algorithm which may be able to locate the light source faster than DFS. Also, I will only be travelling in the x and y directions since the robot will be using the grid lines on the floor to make corrections to it's x and y positions.
I would appreciate it if a fast and reliable algorithm could be suggested to accomplish this task.
This is a really broad question, and I'm not an expert so my answer is based on "first principles" thinking rather than experience in the field.
(I'm assuming that your robot has generally unobstructed line of sight and movement; i.e. it is an open area with scattered obstacles, not in a maze.)
The problem is interpreting the information that you get back from a 360 degree scan.
If the robot sees the light source, then traversing a route to the light source is either trivial, or a "simple" maze walking task.
The difficulty is when you don't see the source. It might mean that the source is not within the circle of visibility. But it could also mean that the light is behind an obstacle. And unfortunately, a simple sensor like you are describing cannot distinguish these two cases.
If your sensor system allowed you to see the obstacles, you could plot the locations of the "shadow" regions (regions behind obstacles), and use that to keep track of the places that are left to search. So your strategy would be to visit a small number of locations and do a scan at each, then methodically "tidy up" a small number of areas that were in shadow.
But since you cannot easily tell where the shadow areas are, you need an algorithm that (ultimately) searches everywhere. DFS is a general strategy that searches everywhere, but it does it by (in effect) looking in the nooks and crannies first. A better strategy is to a breadth first search, and only visit the nooks and crannies if the wide-scale scans didn't find the light source.
I would appreciate it if a fast and reliable algorithm could be suggested to accomplish this task.
I think you are going to need to develop one yourself. (Isn't this the point of the problem / task / competition?)
Although it may not look like it, this looks a more like a maze following problem than anything. I suppose this is some kind of challenge or contest situation, where there's always a path from start to target, but suppose there's not for a moment. One of the successful results for a robot navigating a beacon fully surrounded by obstacles would be a report with a description of a closed path of obstacles surrounding a signal. If there's not such a closed path, then you can find a hole in somewhere; this is why is looks like maze following.
So the basic algorithm I'd choose is to start with a spiraling-inward tranversal, sweeping out a path narrow enough so that you're sure to see a beacon if one is present. If there are no obstacles (a degenerate case), this finds the target in minimal time. (Hint: each turn reduces the number of cells your sensor can locate per step.)
Take the spiral traversal to be counter-clockwise. What you have then is related to the rule for solving mazes by keeping your right hand on the wall and following the generated path. In this case, you have the complication that, while the start of the maze is on the boundary, the end may not be. It's possible of the right-hand-touching path to fail in such a situation. Detecting this situation requires looking for "cavities" in the region swept out by adjacency to the wall.