I am developing a B2C service on demand and I need to create the matching algorithm, simple yet efficient enough to run on a Laravel backend.
The service matches house cleaners with customers, where the customer, when booking, defines a certain date and timeframe when (s)he will be available at home.
On the other hand (#1), cleaners don't have a working schedule and should be picked according to geographical proximity and, of course, availability (not to have two services starting at the same time or too close time-wise one from the other).
Obviously, there should be a geographical limit so that after a certain ε km the algorithm stops searching and, according to the type of service chosen, there is a specific duration.
Another solution (#2) could be to have a predefined weekly schedule and match schedules in order to define a "working calendar" as new requests come.
In any case the cleaner can opt not to accept a booking, in that case the algorithm will continue searching for another possible candidate.
Which algorithm would you suggest for solution #1 and #2?
Thank you
Related
I'm working on an application which organises events. A user enters periods over the course of a week in which they are free, not free, and would prefer to work in.
Once the application is given a list of tasks of varying lengths to complete, it organises them according to the user's avaibalibity and the relative priority of the task.
What kind of algorithm am I looking at using in order to meet the application's requirements?
This is kind of solving a sudoku since multiple invariants need to align for any possible variable of the solution (i.e user must be available for given time period, tasks have priority index etc...).
That means, you can use back-tracking until you find one possible solution/alignment of tasks and return, or possibly continue until you find all possible solutions and return all of them.
I'm trying to increase OptaPlanner performance using parallel methods, but I'm not sure of the best strategy.
I have PDPTW:
vehicle routing
time-windowed (1 hr windows)
pickup and delivery
When a new customer wants to add a delivery, I'm trying to figure out a fast way (less than a second) to show them what time slots are available in a day (8am, 9am, 10am, etc). Each time slot has different score outcomes. Some are very efficient and some aren't bookable depending on the time/situation with increased drive times.
For performance, I don't want to try each of the hour times in sequence as it's too slow.
How can I try the customer's delivery across all the time slots in parallel? It would make sense to run the solver first before adding the customer's potential delivery window and then share that solved original state with all the different added delivery's time slots being solved independently.
Is there an intuitive way to do this? Eg:
Reuse some of the original solving computation (the state before adding the new delivery). Maybe this can even be cached ahead of time?
Perhaps run all the time slot solving instances on separate servers (or at least multiple threads).
What is the recommended setup for something like this? It would be great to return an HTTP response within a second. This is for roughly 100-200 deliveries and 10-20 trucks.
Thanks!
A) If you optimize the assignment of 1 customer to 1 index in 1 of the vehicles, while pinning all other already assigned customers, then you forgoing all optimization benefits. It's not NP-hard.
You can still use OptaPlanner <constructionHeuristic/> for this (<localSearch/> won't improve the score), with or without moveThreadCount to spread it across cores, even though the main benefit will just the the incremental score calculation, not the AI algoritms.
B) Optimize assignment of all customers to an index of a vehicle. The real business benefits - like 25% less driving time - come when adding a new customer allows moving existing customer assignments too. The problem is that those existing customers already received a time window they blocked out in their agenda. But that doesn't need to be a problem if those time windows are wide enough: those are just hard constraints. Wider time windows = more driving time optimization opportunities (= more $$$, less CO² emissions).
What about the response within one minute?
At that point, you don't need to publish (= share info with the customer) which vehicle will come at which time in which order. You only need to publish whether or not you accept the time window. There's two ways to accomplish this:
C) Decision table based (a relaxation): no more than 5 customers per vehicle per day.
Pitfall: if it gets 5 customers in the 5 corners of the country/state, then it might still be infeasible. Factor in the average eucledean distance between any 2 customer location pairs to influence the decision.
D) By running optaplanner until termination feasible=true, starting from a warm start of the previous schedule. If no such feasible solution is found within 1000ms, reject the time window proposal.
Pitfall with D): if 2 requests come in at the same time, and you run them in parallel, so neither takes into account the other one, they could be feasible individually but infeasible together.
The data:
Students which have varying availability at certain timestamps (hourly) throughout the week.
The challenge:
Creating a schedule based on the data above, where a single faculty member can meet with each student once that week, without any overlap between students.
What I have tried so far
Creating a filter that checks which students have the least availability and prioritizing them
Distributing based on days where more/fewer students are available
However, none of my attempts even came close to what I need, and I struggle to understand the mathematics of it all. How can I best create such a scheduling tool above?
Create a bipartite graph with one vertex per student and one vertex per timestamp. A student is connected to a timestamp by an edge if and only if this student is available at that timestamp.
Then search for a maximum matching in this bipartite graph. This is also called the assignment problem, and can be solved for instance with the Hungarian algorithm.
Note that this makes the assumption that timestamps are discrete. This might not correspond to the reality. But it's still a good place to start.
I am currently planning to develop a micro-job platform to match maintenance workers (plumbers, electricians, carpenter, etc) with users in need through geolocation. Bookings can be made well in advance or last minute (minimum 1h before) at the same fare.
Now, I am struggling to find a suited matching algorithm to efficiently assign bookings to available workers. The matcher is basically a listener catching "NewBooking" events, which are fired on a regular basis until a worker is assigned to the specific booking. Workers can accept or decline the job and can choose working hours with a simple toggle button (when it's off they will not receive any request).
On overall the order is assigned within a certain km range.
The first system I thought of is based on concentric zones, whose radius is incremented every time the event is fired (not indefinitely). All workers online within the area will be notified and the first to accept gets the job.
Pros:
more opportunities to match last minute bookings;
Cons:
workers may get a lot of notifications;
the backend processing several push & mail messages;
A second solution is based on linear distance, assigning the work to the nearest available worker and, if (s)he does not accept it within a certain timeframe (like 30'), the algorithm goes to the next available person and so on.
Pros:
less processing power;
scalability with lots of workers and requests;
Cons:
less chances to match last minute orders;
Third alternative is to use the first approach sending orders in multiple batches according to feedback ratings; the first group to receive the notification is made out of those with 4+ stars, then 3+ avg. of votes and so on.
I was wondering if there is a best practice when it comes to this kind of matching algorithms since even taxi apps face these issues.
Anyway, which approach would you suggest (If any), or do you have any proposal on possible improvements?
Thank you
Description:
Our customer interested in logistics wants automated path finding for his business. The issue is that each city, harbor, state, and country has different legal system with different politics for various goods. For example, some goods are forbidden to be transported through the country or fee applies on others, etc.
Intention:
For a given transport of particular goods I need to find the best possible route with a respect to the known politics. If no such route exists, I have to find several the less problematic alternatives.
Questions:
I believe that custom weights of nodes and edges in the graph disqualifies the public maps APIs. The quick search I made showed that no well-known API accepts custom valuation function. Am I right?
I thought that the path finding over custom graph is quite simple even with the custom valuation function. On the other hand, the real world maps are such a giant graph that only thinking about application of conventional algorithms seems silly. Should I think about this solution or is that too complicated and I should look at some other options?
The only thing I can think of to be possible is something like OSPF algorithm - divide the world into regions with their politics and then find the routes only through the possible regions. For these routes for each region find routes through states, etc. That means dynamically change granularity based on the supported geographical objects (countries, states, cities, ...) and slowly converge to the highest granularity, i.e., streets. The bad side of this approach is that it requires a lot of programming as well as lot of computation. Furthermore, I am not sure if maps with such granularity exist and are publicly available. Is this wrong way of thinking or is this too complicated?
What are other options? I could not figure out anything else.