I know the networkx could provide the breadth-first search (bfs) results based on the control of depth. I am wondering is there a workaround so I can control the result with the number of edges? For example, I hope to get 10 edges around a node i by bfs. But I don't know what depth it could be.
The bfs controlled by the depth is something like
bfs = nx.bfs_edges(G, source=i, depth_limit=5)
I hope to use a function something like
bfs = nx.bfs_edges(G, source=i, number=k)
As I hope to find all the edges around a node. So it looks like the nx.edge_bfs is a better option? This function returns all the edges currently. Could we modify it somehow? I hope the source node can be located as center as possible, i.e., the yield edges could evenly around the source node.
After looking at the source code of nx.edge_bfs, it looks like this function itself returns an iterator which yields the edges surround the source node one by one. And it basically returns the surrounding edges like a circle.
It could be better if someone could confirm this. Here is the source link
Related
I am stuck at a current project:
I have an input picture showing the ground with some shapes on it. I have to find a specific shape with a given template.
I have to use distance transformation into skeletonization. My question now is: How can I compare two skeletons? As far as I noticed and have been told, the most methods from the Image Processing Toolbox to match templates don't work, since they are not scale-invariant and rotation invariant.
Also some skeletons are really showing the shapes, others are just one or two short lines, with which I couldn't identify the shapes, if I didn't know what they should be.
I've used edge detection, and region growing on the input so there are only interessting shapes left.
On the template I used distance transformation and skeletonization.
Really looking forward to some tips.
Greetings :)
You could look into convolutions?
Basically move your template over your image and see if there is a match, and where.
The max value of your array [x,y] is the location of your object in the image.
Matlab has a built-in 2D convolution function for this
I'm working on a game that will always be an n x n grid. I'd like to be able to always generate a new start position from the outer edge and have a path to the center cell. My issue is that I want to be able to specify the path length instead of choosing the shortest path. Does anyone have an idea of how to do this?
I've looked at several CompSci forums, but unfortunately I'm unable to make heads or tails of what they're saying.
https://cs.stackexchange.com/questions/44401/what-algorithm-to-use-to-generate-random-path-of-given-length
In order to avoid the hardcore math, I would suggest to always use the shortest possible path and randomly generate and add some pieces to it to make it the length you want. It would not be absolute random, but for sure it should look good enough. Although it depends on your needs.
I've read the document but still confused of them, could any guy can give me a clearly explaining, e.g.any image comparison? Thanks.
The Wikipedia article on Pathfinding might help, as might the related topics on graphs and graph search algorithms linked from there. Beyond that, here's an attempt at a quick explainer.
Nodes are places that someone can be, and their connections to other nodes define someone can travel between places. Together, a collection of (connected) nodes form a graph.
GKGraphNode is the most general form of node — these nodes don't know anything about where they are in space, just about their connections to other nodes. (That's enough for basic pathfinding, though... if you have a graph where A is connected to B and B is connected to C, the path from A to C goes through B regardless of where those nodes are located, like below.)
GKGraph is a collection of nodes, and provides functions that work the graph as a whole, like the important one for finding paths.
GKGridGraphNode and GKGraphNode2D are specialized versions of GKGraphNode that add knowledge of the node's position in space — either integer grid space (like a chessboard) or open 2D space. Once you've added that kind of information, a GKGraph containing these kinds of nodes can take distance into account when pathfinding.
For example, look at this image:
If we're just using GKGraphNode, all we're talking about is which nodes are connected to which. So if we ask for the shortest path from A to D, we can get either ACD or ABD, because it's an qual number of connections either way. But if we use GKGridGraphNode or GKGraphNode2D, we're looking at the lengths of the lines between nodes, in which case ACD is the shortest path.
Once you start locating your nodes in (some sort of coordinate) space, it helps to be able to operate on the graph as a whole in that space. That's where GKGridGraph and GKObstacleGraph come in.
GKGridGraph works with GKGridGraphNodes and lets you do things like create a graph to fill a set of dimensions (say, a 10x10 grid, with diagonal movement allowed) instead of making you create and connect a bunch of nodes yourself.
GKObstacleGraph adds more to free-2D-space graphs by letting you mark areas as impassable obstacles and automatically managing the nodes and connections to route around obstacles.
Hopefully this helps a bit. For more, besides the reference docs and guide, Apple also has a WWDC video that shows how this stuff works.
I would like to find all highway way member nodes in a certain radius. I cannot see how to do this without using intersection, however, that is not in the API. For example I have this:
[out:json];
way(around:25, 50.61193,-4.68711)["highway"];>->.a;
(node(around:25, 50.61193,-4.68711) - .a);
out;
Result set .a contains the nodes I want but also nodes outside the radius - potentially a large number if the ways are long. I can find all the nodes inside the radius I don't need, as returned by the complete query above. Now I can always perform a second around query and do the intersection of the two result sets outside of Overpass. Or I can do another difference:
[out:json];
way(around:25, 50.61193,-4.68711)["highway"];>->.a;
(node(around:25, 50.61193,-4.68711) - .a)->.b;
(node(around:25, 50.61193,-4.68711) - .b);
out;
This gives the result I want but can it be simplified? I'm certain I'm missing something here.
Indeed, your query can be simplified to an extent that we don't need any difference operator at all. I would recommend the following approach:
We first query for all nodes around a certain lat/lon position and a given radius.
Based on this set of nodes we determine all ways, which contain some of the previously found nodes (-> Hint: that's why we don't need any kind of intersection or difference!).
Using our set of highway ways we now look again for all nodes of those ways within a certain radius of our lat/lon position.
In Overpass QL this reads like:
[out:json];
node(around:25, 50.61193,-4.68711);
way(bn)[highway];
node(w)(around:25, 50.61193,-4.68711);
out;
Try it on Overpass Turbo
I am making a game that involves solving a path through graphs. Depending on the size of the graph this can take a little while so I want to cache my results.
This has me looking for an algorithm to hash a graph to find duplicates.
This is straightforward for exact copies of a graph, I simply use the node positions relative to the top corner. It becomes quite a bit more complicated for rotated or even reflected graphs. I suspect this isn't a new problem, but I'm unsure of what the terminology for it is?
My specific case is on a grid, so a node (if present) will always be connected to its four neighbors, north, south, east and west. In my current implementation each node stores an array of its adjacent nodes.
Suggestions for further reading or even complete algorithms are much appreciated.
My current hashing implementation starts at the first found node in the graph which depends on how i iterate over the playfield, then notes the position of all nodes relative to it. The base graph will have a hash that might be something like: 0:1,0:2,1:2,1:3,-1:1,
I suggest you do this:
Make a function to generate a hash for any graph, position-independent. It sounds like you already have this.
When you first generate the pathfinding solution for a graph, cache it by the hash for that graph...
...Then also generate the 7 other unique forms of that graph (rotated 90deg; rotated 270deg; flipped x; flipped y; flipped x & y; flipped along one diagonal axis; flipped along the other diagonal axis). You can of course generate these using simple vector/matrix transformations. For each of these 7 transformed graphs, you also generate that graph's hash, and cache the same pathfinding solution (which you first apply the same transform to, so the solution maps appropriately to the new graph configuration).
You're done. Later your code will look up the pathfinding solution for a graph, and even if it's an alternate (rotated, flipped) form of the graph you found the earlier solution for, the cache already contains the correct solution.
I spent some time this morning thinking about this and I think this is probably the most optimal solution. But I'll share the other over-analyzed versions of the solution that I was also thinking about...
I was considering the fact that what you really needed was a function that would take a graph G, and return the "canonical version" of G (which I'll call G'), AND the transform matrix required to convert G to G'. (It seemed like you would need the transform so you could apply it to the pathfinding data and get the correct path for G, since you would have just stored the pathfinding data for G'.) You could, of course, look up pathfinding data for G', apply the transform matrix to it, and have your pathfinding solution.
The problem is that I don't think there's any unambiguous and performant way to determine a "canonical version" of G, because it means you have to recognize all 8 variants of G and always pick the same one as G' based on some criteria. I thought I could do something clever by looking at each axis of the graph, counting the number of points along each row/column in that axis, and then rotating/flipping to put the more imbalanced half of the axis always in the top-or-left... in other words, if you pass in "d", "q", "b", "d", "p", etc. shapes, you would always get back the "p" shape (where the imbalance is towards the top-left). This would have the nice property that it should recognize when the graph was symmetrical along a given axis, and not bother to distinguish between the flipped versions on that axis, since they were the same.
So basically I just took the row-by-row/column-by-column point counts, counting the points in each half of the shape, and then rotating/flipping until the count is higher in the top-left. (Note that it doesn't matter that the count would sometimes be the same for different shapes, because all the function was concerned with was transforming the shape into a single canonical version out of all the different possible permutations.)
Where it fell down for me was deciding which axis was which in the canonical case - basically handling the case of whether to invert along the diagonal axis. Once again, for shapes that are symmetrical about a diagonal axis, the function should recognize this and not care; for any other case, it should have a criteria for saying "the axis of the shape that has the property [???] is, in the canonical version, the x axis of the shape, while the other axis will be the y axis". And without this kind of criteria, you can't distinguish two graphs that are flipped about the diagonal axis (e.g. "p" versus "σ"/sigma). The criteria I was trying to use was again "imbalance", but this turned out to be harder and harder to determine, at least the way I was approaching it. (Maybe I should have just applied the technique I was using for the x/y axes to the diagonal axes? I haven't thought through how that would work.) If you wanted to go with such a solution, you'd either need to solve this problem I failed to solve, or else give up on worrying about treating versions that are flipped about the diagonal axis as equivalent.
Although I was trying to focus on solutions that just involved calculating simple sums, I realized that even this kind of summing is going to end up being somewhat expensive to do (especially on large graphs) at runtime in pathfinding code (which needs to be as performant as possible, and which is the real point of your problem). In other words I realized that we were probably both overthinking it. You're much better off just taking a slight hit on the initial caching side and then having lightning-fast lookups based on the graph's position-independent hash, which also seems like a pretty foolproof solution as well.
Based on the twitter conversation, let me rephrase the problem (I hope I got it right):
How to compare graphs (planar, on a grid) that are treated as invariant under 90deg rotations and reflection. Bonus points if it uses hashes.
I don't have a full answer for you, but a few ideas that might be helpful:
Divide the problem into subproblems that are independently solvable. That would make
How to compare the graphs given the invariance conditions
How to transform them into a canonical basis
How to hash this canonical basis subject to tradeoffs (speed, size, collisions, ...)
You could try to solve 1 and 2 in a singe step. A naive geometric approach could be as follows:
For rotation invariance, you could try to count the edges in each direction and rotate the graph so that the major direction always point to the right. If there is no main direction you could see the graph as a point cloud of its vertices and use Eigenvectors and Priciple Compoment Analysis (PCA) to obtain the main direction and rotate it accordingly.
I don't have a smart solution for the reflection problem. My brute force way would be to just create the reflected graph all the time. Say you have a graph g and the reflected graph r(g). If you want to know if some other graph h == g you have to answer h == g || h == r(g).
Now onto the hashing:
For the hashing you probably have to trade off speed, size and collisions. If you just use the string of edges, you are high on speed and size and low on collisions. If you just take this string and apply some generic string hasher to it, you get different results.
If you use a short hash, with more frequent collisions, you can get achieve a rather small cost for comparing non matching graphs. The cost for matching graphs is a bit higher then, as you have to do a full comparison to see if they actually match.
Hope this makes some kind of sense...
best, Simon
update: another thought on the rotation problem if the edges don't give a clear winner: Compute the center of mass of the vertices and see to which side of the center of the bounding box it falls. Rotate accordingly.