Workflow
The Running Dinner Planner uses various mathematical techniques to create a balanced seating arrangement where both Houses and Participants are divided as equally as possible between the various Courses and Tables. The primary target is to avoid people meeting each other more than once. This often turns out to be a difficult and time-consuming task. In fact, it is mathematically known that it is sometimes impossible (see FAQ). The app searches the solution space in a pseudo-random manner, starting both from a situation where no Houses and no Participants have been assigned, as well as from a point where enough pseudo-Participants and pseudo-Houses have been added such as to make an ‘ideal’ solution possible where no two people meet each other twice. In both approaches, the app calculates solutions honouring any preset input the user cares to give - these are called ‘current’ solutions and are, marked with an asterisk (*). It however also creates solutions where no user input is taken into account - these are dubbed ‘virgin’ solutions.
The problem becomes even more involved when demands such as a balanced M/F ratio at any Table, Houses being assigned their preferred Course to serve, and the need for certain individuals to not be seated together are taken into the equation.
In its search for the best solution, the app assigns a Penalty to any arrangement it finds, based on which of these (often conflicting) demands are met and to what extent. The arrangement with the lowest penalty is often the most desirable one ( though the ultimate choice as to which is the best is of course left to the user). The penalties associated with each demand are crucial in steering the app towards the desired result. These can be adjusted manually but, in a typical case, the default values work fine. The user is therefore not encouraged to change these values - but it is possible to do so.
In order to accomplish its task the Planner app needs, at a minimum, the names of the Participants and the addresses of the Houses where they live. This data can be inputted into the system by way of the dark-blue buttons shown in the main workflow. Use of the light-blue buttons is optional, and can be used to change default values such as the number of Courses involved, any preferences certain Houses have to cater a certain Course, any ‘should not be seated next to each other’ relations between Participants, etc.
In summary: almost all parameters can be inputted by the user, but for most cases only the dark-blue buttons need to be used to provide the minimum input.