The way I envision any scheduling system to work is by (1) a brute force program generating a feasible but poor schedule subject to hard constraints and (2) some probabilistic algorithm(s) optimizing said poor schedule given a number of things to weigh in.
I’ve already written a quick brute force program 1. The result is the attached file. Please look at the attached file, and consider why the schedule is so poor. In order for the schedule to get better, we need to figure out what makes a schedule good and what data we will need in order to measure that. Some of this is tricky since it’s so intuitive.
I’ve written below a list of what I think are some pieces missing. Any text in square brackets ([….]) are data that I’ve identified we will likely need/use in order to implement the constraint.
FEASIBILITY PROBLEMS (aka hard constraints)
- For Splash, some timeslots only work with certain grade ranges. Timeslots don’t know this. I’m not sure how we should encode this type of constraint, but we would need