I searched for the algorithm/pseudocode of A* I followed it and coded it. I used Manhattan distance for h(n). ( f(n) = g(n) + h(n) )
And this is the result,
This always happen when there are no walls blocking the way, but when I put a lot of walls, it seems that it's taking the shortest path. Is this one the shortest path? I mean why is it not like this one below?
This one is also A* Manhattan, and they have the same size (19x19). This is from http://qiao.github.com/PathFinding.js/visual/
Both paths have the same manhattan distance. Therefore, it is implementation dependant which path is chosen. To tell why this specific part was chosen, we would have to look at the code of this specific A* implementation.
Hint: Every path from a source to a target cell that uses only Von Neumann neighborhood(i.e., does not walk diagonally) and does not take a step into the "wrong" direction (i.e., never walks up or left in your example) has the same manhattan distance. So, if you are in New York, it doesn't matter which crossroads you take to reach a certain place in Manhattan :)
With the manhattan distance the first one is a shortest path. It simply counts the number of horizontal and vertical steps taken. If you want something that looks more like a shortest path in the euclidian distance you can try changing your algorithm so that when it has the choice to move horizontally or vertically at one point it chooses the horizontal one if the horizontal distance is bigger than the vertical one and vice versa.
You need to cast a line of sight (pythagorean/euclidean) from starting point to every point(of the manhattan/A* result) until finish. If casting a line to a certain point is blocked/hidden by the obstacle, you use the previous point casted and start casting another line from that blocked point then forward until finish.
A Blocked point is when a point is hidden by the line-of-sight of the initial point of the segment/line.
So It's like:
First Line: Start--------->S+N(before blocked point)
Second/Middle Line/s:Blocked Point---------->S+N(before another blocked point) repeat again(new line/segment) until it established a line-of-sight to the goal.
Last Line:Blocked Point------------->Goal
Connect all lines and you've got a much shorter shortest path.
You can execute again, but in reverse to add another accuracy so the line of sight will begin at the goal until start.
Related
I am not an experienced programmer (programming language MATLAB) and hence have barely any knowledge of advanced algorithms. One of these is the breadth-first search. The concept I understand but implementing it into my problem is difficult for me.
My problem:
I place disks, of equal sizes, randomly in a square and will place the coordinates of the disks into separate matrices when they are one connected network. I colorized them for clarity (see image). Now, I have to find the shortest path from left to right of the network which spans from left to right and want to do this based on the coordinates. The disks have to touch in order to be connected to each other. They cannot form a path if they are not touching.
So this is what I currently have:
I have a matrix with coordinates x and coordinates y in columns 1 and 2, every row representing one of the disks (for ease, let's just take the coordinates of all the connecting disks, excluding those which are not spanning from left to right when connected).
The diameter of the disks is known (0.2).
We can easily identify which disks are on the left boundary of the square and which disks are on the right boundary of the square. These represent the possible starting coordinates and the possible goal coordinates.
% Coordinates of group of disks, where the group connects from left to right.
0.0159 0.1385
0.0172 0.2194
0.0179 0.4246
0.0231 0.0486
0.0488 0.1392
0.0709 0.2109
0.0813 0.0595
0.0856 0.3530
0.1119 0.3756
0.1275 0.2530
0.1585 0.4751
0.1702 0.2926
0.1908 0.3828
0.1961 0.3277
0.2427 0.4001
0.2492 0.4799
0.2734 0.4788
0.3232 0.3547
0.3399 0.3275
0.3789 0.3716
0.4117 0.3474
0.4579 0.3961
0.4670 0.3394
0.4797 0.3279
0.4853 0.4786
0.3495 0.4455
0.4796 0.2736
0.0693 0.0746
0.1288 0.4204
0.1271 0.4071
0.1218 0.4646
0.1255 0.3080
0.4154 0.2926
Positions of disks and colored the connecting disks. Image is very schematic and many more disks should be expected in a much larger area (keeping same size disks).
My strategy was to set up a breadth-first search, taking the starting coordinates as one of the disks (can be any) on the left side of the square. The goal will be to find the shortest path to the right side of the square.
To my understanding, I want to pick a starting coordinate and check all disks if they are within a diameter distance (middle point to middle point of the disks) of my starting coordinate. If they are within range of my starting coordinate I want to place them in a 'queue' (natively not supported by MATLAB? but let's set one up ourselves). Then, the next step is to take the first disk which was close enough and do the same for this one. I can do this but once I have to do the second disk which was within my first disk, I am lost in how and/or what data structure I should take and how to save the 'path' which it is finding. This means I can find a path but not all paths and hence also not the shortest path.
I appreciate any help! Maybe some documentation which I have not seen yet or maybe an example which is very comparable.
Best regards,
If they are within range of my starting coordinate I want to place
them in a 'queue'
Before you add it to the queue you want to make sure this disk was not processed (put in the queue) before. Each disk should be processed only once, so you make sure the "neighbor" disk has not been processed before, then mark it as processed and add it to the queue.
the next step is to take the first disk which was close enough and do
the same for this one.
Actually the next disc to process is simply the one at the head of the queue.
Continue to do so until you hit the target / stop criteria.
how to save the 'path' which it is finding
There are several techniques to do so. An easy one would be to maintain a "come from" value to each disk. This value points to the "parent" of the disk.
Since each disk is processed once (at most) it will have one "come from" value or none.
When the target is reached the path can be reconstructed starting from the "come from" value of the target.
This question has now been solved!
The way I have solved this was close to what was already suggested in my question but also with help from some of the comments.
The distance between coordinates can be put into a matrix. Let us look at coordinate (disk) 1 and coordinate (disk 3). This means that we will be at elements (1,3) and (3,1). If the disks are within touching distance, these two elements will indicate a 1 and otherwise a 0. This is done for all disks and this creates the adjacency matrix.
I created a 'graph' with the built-in function G = Graph(adjacency matrix) we can create an undirected graph. Then with the built in function [path, distance of path] = shortestpath(G,s,t) where G is the graph and s and t are the starting disks (in this case, indicated by integers), the shortest path can be found from disk s to t.
There is however one thing that we must pay attention to and that is representing the actual distance between disks. If we look at G, we can actually see that it contains two objects. One representing the nodes and the other representing the edges. The edges is crucial for the coordinate based distances as we can set the 'weight' of the edge as the distance between two disks. This can simply be done by looping over the nodes and calculating the distance between the neighbouring nodes and inserting them into the weight (G.Edges.Weight(i) = distance between the respective nodes).
How do I find the optimal path from left to right? I loop over all starting disks (defined as touching the left side of the square) and find the shortest path to all disks that touch the right side of the square. Saving the distances of the paths the actual shortest path can be found.
To give you an example of what can be achieved, the following video shows what paths from every starting disk can be found and the final frame shows the shortest path. Video of path finding. The shortest path I have also attached here:
Shortest path left to right.
If there are any questions you would like to ask me about specifics, let me know.
I have the following problem and I am a bit clueless how to tackle it as my programming skills are very elementary ( I am an engineer, so please dont bite my head off).
Problem
I have a point cloud, the picture above displaying one level off it. Every point is a centroid off a block (x =5, y=1, z=5) and is specefied by carteisian coordinates.
The centroids further have two values: one called "access" and one "product". If the product value is positive and pays for the access to the point I want to include it in my outcome. The red marker in the picture represents a possible starting point.
Starting Idea
As a start I am trying to set up an algorithm, that starts at the red marker, runs through the blocks left and right (along the x-axis), checks until where it would be feasible to access (so sum "product" > sum "access") and then goes to the next point (in y direction from marker) and does the same until the end of the level.
Final Goal
My final goal is that I can Flag points as accessed and the algorithm connects profitable "products" (so products that would pay for their access) on the shortest way to the access point (by setting blocks/points on the way to accessed).
I know this is a very open question and I apologize for that. I am just lacking a good starting point programming wise. I was thinking of knnsearch, but I am not sure if this is the right way to go as the blocks have different sizes and i technically want the nearest neighbour in every direction but also only one per direction.
Another idea I had was using shortestpath or creating a travel salesman problem out of it, but I am not sure how to properly implement it.
If you have any ideas or you could offer any help I would very much appreciate it. If any more information is needed I gladly provide it.
I am using SpriteKit and I need to calculate the fall time of an object (since it changes depending on the screen size). The problem is that the gravity of the scene is given in m/s^2, but all distances are measured in points.
I have tried to find the conversion between points and meters, but it was not very successful.
Any suggestions in how to deal with it?
You may be able to use something like this (A distance calculator written by another on StackOverflow) to calculate the distance between your node and the point directly below it near the ground or another empty node, then plug that distance into an equation to calculate the time.
Unfortunately, I can't give you any code because I've never tried this myself.
When doing SPH, the paper by Kelagar recommends using a particular kernel for pressure induced forces between particles. The kernel it recommends is the following when the radius is within the kernel radius:
(15/(pi*h^9)) * (h - r)^3
where h is the kernel radius, and r is the radius we are interested in calculating the value of a function at.
The paper then states that the gradient of this function is
(-45/(pi*h^9))*((r_vec)/r)*(h-r)^2
where r_vec is now the vector from the center of the kernel to the point we are interested in. As length of r_vec goes to 0 from the positive direction, the paper states that this gradient approaches:
(-45/(pi*h^6))
But this is a scalar, not a vector. In order for there to be a repulsion between the two points we're interested in, there needs to be a direction to repel in.
What direction should we use for when two particles are right next to each other?
I assume that first expression is meant to be a potential. The negative gradient (derivative with respect to r) is then the force. This gradient is a vector, always pointing toward or away from the center. This appears correct for the second expression.
r_vec is, according to what you say, a vector pointing away from the origin to a point at some distance r away. (r_vec/r) is then a unit vector to specify direction. This works at every point except the origin itself, where it can be declared undefined, or declared to be zero. Zero is the average value of (r_vec/r) over all "nearby" points. This means zero force.
Normally in particle simulations with pair-wise forces, we ignore forces of a particle on itself, and of two particle at the same exact position. What about two particle very close, and you have a force law that goes like 1/r, 1/(r^2), or similar? Nobody wants a divide by zero fault. Usually there's a small radius below which the potential is constant matching the given potential formula at the boundary of that radius. Particles too close together have zero force, just so that the simulation won't crash. It may seem unphysical for the force to suddenly cease just inside that boundary when it is fiercely strong just outside it. But we strive to avoid such situations. Keep count of such incidences, and if there are too many, the simulation has gone bad. Maybe a smaller time step is needed.
Luckily you don't have a 1/r type of force, but still you have that nasty r_vec/r whose direction can swing wildly. The same technique of making force zero below a certain tiny radius will help.
But that third expression bothers me. If it's force at r=0, then starting with the force law in the second expression, I'm not sure how the third expression comes about. The problem of it looking scalar while, if it is supposed to be force, expecting vector could be resolved by understanding that it is meant to be the radial component of a force vector. Just multiply the expression by (r_vec/r), the familiar unit-magnitude vector. OTOH, it has no defined direction, so it is nonsense.
Better overall solution: start with a new potential function, one that smoothly levels off and is flat right at r=0, like exp(-r^2) or 1/(1+r^2). The given potential peaks sharply. You want something more like Instead of declaring force zero inside some small zone, the force would just naturally be zero at r=0. Find a flat-at-origin potential that approximates the given one well outside some small radius.
I have a table that contains a bunch of Earth coordinates (latitude/longitude) and associated radii. I also have a table containing a bunch of points that I want to match with those circles, and vice versa. Both are dynamic; that is, a new circle or a new point can be added or deleted at any time. When either is added, I want to be able to match the new circle or point with all applicable points or circles, respectively.
I currently have a PostgreSQL module containing a C function to find the distance between two points on earth given their coordinates, and it seems to work. The problem is scalability. In order for it to do its thing, the function currently has to scan the whole table and do some trigonometric calculations against each row. Both tables are indexed by latitude and longitude, but the function can't use them. It has to do its thing before we know whether the two things match. New information may be posted as often as several times a second, and checking every point every time is starting to become quite unwieldy.
I've looked at PostgreSQL's geometric types, but they seem more suited to rectangular coordinates than to points on a sphere.
How can I arrange/optimize/filter/precalculate this data to make the matching faster and lighten the load?
You haven't mentioned PostGIS - why have you ruled that out as a possibility?
http://postgis.refractions.net/documentation/manual-2.0/PostGIS_Special_Functions_Index.html#PostGIS_GeographyFunctions
Thinking out loud a bit here... you have a point (lat/long) and a radius, and you want to find all extisting point-radii combinations that may overlap? (or some thing like that...)
Seems you might be able to store a few more bits of information Along with those numbers that could help you rule out others that are nowhere close during your query... This might avoid a lot of trig operations.
Example, with point x,y and radius r, you could easily calculate a range a feasible lat/long (squarish area) that could be used to help rule it out if needless calculations against another point.
You could then store the max and min lat and long along with that point in the database. Then, before running your trig on every row, you could Filter your results to eliminate points obviously out of bounds.
If I undestand you correctly then my first idea would be to cache some data and eliminate most of the checking.
Like imagine your circle is actually a box and it has 4 sides
you could store the base coordinates of those lines much like you have lines (a mesh) on a real map. So you store east, west, north, south edge of each circle
If you get your coordinate and its outside of that box you can be sure it won't be inside the circle either since the box is bigger than the circle.
If it isn't then you have to check like you do now. But I guess you can eliminate most of the steps already.