Closed LouisCG closed 8 years ago
The 'pluggable algorithms' line is a little cheesy, but I guess keeping a mind for extensibility was a good choice.
I've reverted the changes to the DFS algorithm. Ready for further consideration.
I reverted the changes to constraint_factory as some other parts of the code were complaining. sim-anneal now references FixtureInterface from dfs until such time as FixtureInterface gets its own file in util or something.
We have simulated annealing now. It's pretty neat. It can also do the team-level constraints. It makes the bungee-backtracking dfs algorithm look like trash.
This pull deals with #89 and #90 in the capacity of the algorithm. I'm not sure whether we should be closing those issues until the algorithm is integrated, tests are made, and so on. However, I haven't slept or stopped working from the last time we met, so I'm a little too exhausted to get the complete surrounding work done. I think it's going to be important that you guys look over this before we sweat the small stuff anyway.
This algorithm does not make use of the ConTable like DFS does. It has it's own data structure called CostsTable, that serves a very different purpose. Quick lookups and storage of constraint state.
Because simulated annealing requires very fast lookups to be worth it and requires to measure the severity and not just the presence of broken constraints, the CostsTable checks team-level constraints by simply calling getter functions and doing its own checks. I've added the necessary getters to the Team interface. ConstraintsSatisfied is not required for the algorithm, but it may still prove convenient for checking constraints in the UI during manual matchmaking.
I'm about to fall asleep on my keyboard. Have an explore and I can get to your questions later.
Also be advised that I have to get another assignment done by Friday. I will not be able to make drastic changes, however I can give advice if needed.