![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
One of the problems I've idly wanted to solve for a long time is the problem of automatic scheduling suggestion: you have a variety of things you want to do, but you don't know how to fit them all in.
Or, you have a variety of people wanting to find a meeting time, and have to poke around trying to find one that works. Blech!
I came up with a toy solver for that tonight using Prolog - it's over on a gist on my github account.
This particular solution aggressively leverages Prolog's unification facilities. First, I assert that a set of slots are available, then I have a query that determines available times.
In the available_times/3 predicate, it has three parameters - the first param (people being matched for) is a list pattern-matched into P1/PRest, then the timeslots. The head represents a person - we unify their availability, summoning the set of matching timeslots. Then, we move on down the list of people recursively with the Rest list. Eventually we terminate when the Rest list is nil. The key idea is that the Day & Time slots are being unified and the clauses in the query are *also* being unified. Therefore any solution for an individual person in the recursion chain is intersected with the solutions for the other people in the recursion chain; if there is an available timeslot found, it will be returned.
all_availability/2 is a mechanism to take a personlist and return a list of 3-tuples assigned to bag, using the findall/3 predicate.
It would be nifty to tweak this so that it was boosted to the point where, e.g., a list of classes w/ timeslots could be fed to it, then a set of possible class schedules spat out. Add on a prioritization scheme (must/may), a decent UI (Prolog's native CLI is awful), and this would be very useful.
Or, you have a variety of people wanting to find a meeting time, and have to poke around trying to find one that works. Blech!
I came up with a toy solver for that tonight using Prolog - it's over on a gist on my github account.
This particular solution aggressively leverages Prolog's unification facilities. First, I assert that a set of slots are available, then I have a query that determines available times.
In the available_times/3 predicate, it has three parameters - the first param (people being matched for) is a list pattern-matched into P1/PRest, then the timeslots. The head represents a person - we unify their availability, summoning the set of matching timeslots. Then, we move on down the list of people recursively with the Rest list. Eventually we terminate when the Rest list is nil. The key idea is that the Day & Time slots are being unified and the clauses in the query are *also* being unified. Therefore any solution for an individual person in the recursion chain is intersected with the solutions for the other people in the recursion chain; if there is an available timeslot found, it will be returned.
all_availability/2 is a mechanism to take a personlist and return a list of 3-tuples assigned to bag, using the findall/3 predicate.
It would be nifty to tweak this so that it was boosted to the point where, e.g., a list of classes w/ timeslots could be fed to it, then a set of possible class schedules spat out. Add on a prioritization scheme (must/may), a decent UI (Prolog's native CLI is awful), and this would be very useful.
