I am trying to implement Branch and Bound approach to the edit distance algorithm. I can't find any hints over internet to start with. Can anyone help me to get into the track of the algorithm.
My apologies for posting this as an answer, I wanted to add it as just a comment, but I don't have sufficient reputation to add comments.
Try to approach your literature search of this subject rather in the context of the graph similarity problem than for the edit distance algorithm; the prior is a more general and well-studied problem which the problem of finding the minimum edit distance fall under. The strings in any instance of your edit distance problem can be described as simple directional graphs, and the operations of insertion/deletion and substitution in the edit distance algorithm has similar operations in the graph similarity problem (e.g., insertion of vertices and edges/deletion of vertices and edges/changing labels on edges and so on).
Related
Using the Mapbox Optimization API is it possible to optimize the routes between multiple drivers?
Example: 6 locations are added, 2 drivers are added, the routes get split / optimized between the two drivers
I'm still in the planning stage, so I haven't poked around too much myself yet, but the code and all the examples I've seen are directed towards single driver optimization only... Has anybody done something like this before? Anything you can recommend to point me in the right direction?
Mapbox's Optimization API returns a duration-optimized route between the input coordinates, which is also known as solving the so-called "Travelling Salesman Problem". This is a well-known, NP-hard graph theory problem, meaning there is no general polynomial-time solution known for the problem.
The underlying data used for computing the aforementioned duration-optimized route are the cost functions of the edges connecting the coordinates input to the API request. You could retrieve the cost values (including traffic) between a set of these coordinate positions using Mapbox's Matrix API.
Adding a second driver/salesman to the problem makes the problem exponentially harder to solve, as discussed in the answer to this Stack Overflow post.
Here is a link to a scientific paper discussing a possible approach to this problem.
As evidenced by the research community, a solution for the Multiple Travelling Salesman Problem is not straightforward to implement. If you do not want to engage in this non-trivial task of implementing an algorithm that would solve it for you, you could implement a function that will make an educated guess on how to split up the destination coordinates between the two drivers. This "educated guess" could be based on values obtained from the Matrix API. You could make a one-to-many request for each driver, then take the lesser of the two durations for each coordinate and assign the coordinate to the appropriate driver. Then, you can use Mapbox's Optimization API to solve the two separate travelling salesman problems individually.
Even if you did implement an algorithm that would solve the Multiple Travelling Salesman Problem, the problem's complexity grows exponentially with the number of drivers and the number of waypoints. Therefore, you could end up with a solution that works, but would not necessarily compute in a reliable amount of time. These performance limitations are something to keep in mind when going about implementing a solution.
My professor said that I should find a way to find the number of triangles in a graph. I have a problem what graph should I used but my professor suggested that I must first find a way to count the triangles in a graph. I've searched it through Google and I found that there's an algorithm in counting the triangles in a graph but I don't understand much about it because I'm not a ComSci (Computer Science) student. And I also found that I can count the number of triangles by matrix. (1/6)(A)^3. It's a trace of A. So... what I'm asking right now is another idea of finding the number of triangles in a graph. Thank you if I got an answer!
A simple approach is to visit each node and try each path from it that has length 3. If it end at the start-node it will be a triangle.
This is not optimal considering time consumption, but it is simple.
I want to implement some kind of improvement of DBSCAN algorithm, where user do not need to enter input parameters (minPts and Eps). My idea is to use the K-distances plot, but what is the best method to compute the 'knee' of this plot? How to count when there are 2 or more knees on the plot?
Where I can find the source code for some DBSCAN improvement, like AUTODBSCAN, VDBSCAN, PDBSCAN or DBSCAN-DLP? Im looking for some basics, but nowhere I can find a good help. Maybe you've seen somewhere sample source codes?
DBSCAN has already been improved to death.
In Google Scholar, it has 5361 citations, and probably 1000+ of these "improve" DBSCAN. And probably a dozen of these use the k-distance plot. But none of these are used in practise.
If you want to continue this line of research, best get updated on what has been done since.
In particular, have a look at OPTICS which does away with the Epsilon parameter completely (except for performance reasons when using indexes).
Also have a look at HDBSCAN* by one of the original DBSCAN authors, Joerg Sander. That will likely be the most important DBSCAN extension besides his work on OPTICS and GDBSCAN.
i know about the traveling salesman problem, but is there any other algorithm/problem which better fits my needs/description? I need to describe my problem with the help of such a mathematical description.
I have a set of nodes with known start- and endpoint. So i just need to calculate the shortest way to visit all the three points between that two. Dijkstra and similar algorithms try to find the shortest path between two points, so here they probably won´t visit all points between. Or is there a algorithm which finds shortest way and visit all points between two points?
You can achieve it using Ant colony optimization algorithms. Refer Ant colony optimization algorithms.
The complexity of the general case of your problem is at least as high as for the Travelling Salesman problem. Just imagine the case where your two endpoints are basically in the same position, then your problem becomes equivalent to the Travelling Salesman.
If you never expect more than five points in your graph though, do you really need to bother with fancy algorithms? You could just do an exhaustive search for the best solution. Since the only decision is the order in which you visit the three points in the middle, you will only have to test 3! = 6 different paths. Even if I misunderstand you and you want the overall shortest open path that visits all nodes, that would still only be 5! = 120 different paths to test (60 if distances are the same in both directions).
I need to program an algorithm to navigate a robot through a "maze" (a rectangular grid with a starting point, a goal, empty spaces and uncrossable spaces or "walls"). It can move in any cardinal direction (N, NW, W, SW, S, SE, E, NE) with constant cost per move.
The problem is that the robot doesn't "know" the layout of the map. It can only view it's 8 surrounding spaces and store them (it memorizes the surrounding tiles of every space it visits). The only other input is the cardinal direction in which the goal is on every move.
Is there any researched algorithm that I could implement to solve this problem? The typical ones like Dijkstra's or A* aren't trivialy adapted to the task, as I can't go back to revisit previous nodes in the graph without cost (retracing the steps of the robot to go to a better path would cost the moves again), and can't think of a way to make a reasonable heuristic for A*.
I probably could come up with something reasonable, but I just wanted to know if this was an already solved problem, and I need not reinvent the wheel :P
Thanks for any tips!
The problem isn't solved, but like with many planning problems, there is a large amount of research already available.
Most of the work in this area is based on the original work of R. E. Korf in the paper "Real-time heuristic search". That paper seems to be paywalled, but the preliminary results from the paper, along with a discussion of the Real-Time A* algorithm are still available.
The best recent publications on discrete planning with hidden state (path-finding with partial knowledge of the graph) are by Sven Koenig. This includes the significant work on the Learning Real-Time A* algorithm.
Koenig's work also includes some demonstrations of a range of algorithms on theoretical experiments that are far more challenging that anything that would be likely to occur in a simulation. See in particular "Easy and Hard Testbeds for Real-Time Search Algorithms" by Koenig and Simmons.