0

I have a number of cities. I can travel from any city to any another city but I can't know what cities are in my route. I know only the distance (or traveling time, cost) from start to finish point. Think like it's airway.

I also have a list of deals (multiple per city) that I can complete by travelling from one city to another (1 deal - 1 travel). A deal profit is a one-directional and is once-applied (revisiting allowed but will not bring a profit) positive number between two cities. Multiple deal-starting cities can target the same one end-city.

I can't do more than one deal at a time and I have a limited number of money in my pockets. Some deals I can even partially complete because of luck of money. So I may return to the deal-starting city and complete the next part of the deal.

How can I build cities-deals schedule to make the best profit at smallest time? Oh, and I can ignore deals. The goal is not to achieve every deal but to make better profit per time. Any ready alghorithms?

Now I'm just using greedy alghorithm and go from one most profitable (per travel distance from current location) deal to another.

Gates

Vlad
  • 3,001
  • 1
  • 22
  • 52
  • There is a small contradiction in your problem: _to make the best profit at smallest time_. You should first choose, what will be solution: max profit or min time? Or some kind of objective function that includes both. – Alex Salauyou Apr 12 '14 at 13:18
  • One more thing that is unclear: after finishing a deal, can you spend this money to further trips, or you can spend just money from the starting amount? – Alex Salauyou Apr 12 '14 at 13:25
  • @Salauyou 1) Ok, let's limit a total travelling cost. The schedule is fulfilled when the limit is reached. 2) The money amount is not going to increase very fast while travelling (~30% per 10 cities visited) and the schedule should be recalculated in a time period to consider new accessable deals. Assume that there is a permanent money amount per calculation. – Vlad Apr 12 '14 at 23:02
  • @Salauyou " after finishing a deal, can you spend this money to further trips" - yes, we have the same money amount at any city – Vlad Apr 12 '14 at 23:05
  • I've implemented n^2 searching. Actually I retrieve deals within closest region from remote web service so it is's long operation including parsing, caching, filtering, calculating distances and profit per distance so the calculation takes *very* long... – Vlad Apr 12 '14 at 23:44
  • So, to make your task problem more formal: given a graph, with edges (c, d), where c is cost of traveling through the edge, d is profit received. With a given amount of money C, you should find the path through edges so that total sum of c(i) will not exceed C, and sum of profits d(i) will be maximum possible. – Alex Salauyou Apr 12 '14 at 23:47
  • you are very lucky with O(n^2) complexity, Dijksta algorithm has the same complexity. For instance, travelling salesman problem solution has complexity of O(n!), you know... If O(n^2) doesn't satisfy you, you should analyze data to search for heuristics that could help. Or maybe have a look at some approximate approach (like genetic algorithm) if it is satisfactory to go with approximate solutions... – Alex Salauyou Apr 12 '14 at 23:52
  • @Salauyou 1) when profit is received it's removed (marked as "used") from edge so it can't be received twice. 2) there could be many deals on the same edge but only one can be "used" at a time. an edge of course could be revisited. 3) edges profit is one-directional 4) " total sum of c(i) will not exceed C " - no. any received c should not exceed C. but you can "split" c and travel many times on the same edge. 5) sorry for my mistake, actually it's n^n complexity – Vlad Apr 12 '14 at 23:56
  • @Salauyou After n^n I've tried to limit valid options in every "n" by ordering profits per cost and selecting first X elements(like in a greedy alghorithm). Also I'm decreasing X each time when the recursion goes deeper so it turns n!. Now it returns not the most optimal schedule but it's a little more efficient than the greedy variant. And it's still very time consuming calculation - takes ~10 minutes for 5!. – Vlad Apr 13 '14 at 00:08
  • are you familiar with genetic approach? it is easy to implement and execution time can be strictly controlled – Alex Salauyou Apr 13 '14 at 01:27
  • @Salauyou no, where can I start? – Vlad Apr 13 '14 at 09:48
  • @Salauyou I redone my search alghorithm to use "wide" search (not deep) without recursion and I also optimized my calculations. Just want to say that now it works well enough for me (~15 depth in a ~10 minutes). – Vlad Apr 14 '14 at 22:47

0 Answers0