Running Dinner Planner
Advanced Settings
In this screen the user can change various settings that influence how the app’s optimisation routines operate when trying to find the most optimal seating arrangement.
Note: It is not recommended to change these settings from their default values unless the operator has an in-depth knowledge of how they operate, as it may result in the app crashing.
Set to recommended defaults
This button resets the values of all the Settings to their default value.
User details
Here, you can provide the login credentials of your MyPlanner account, which allows you to conveniently input data like names and addresses via the web-interface (see e.g., the 2-minute tutorial), and transfer them to your phone via the cloud (
Optimisation method
There are two ways in which the Planner app tries to find an optimal Configuration (aka Solution, aka Seating Arrangement): method 1 and method 2, When the slider is shifted completely to the left, method 1 is used; when it’s shifted completely to the right, method 2 is used. For positions in-between, the app balances the use of methods 1 and 2.
Method 1: minimum number of pre-set placements.
The first uses as a starting point a Configuration that either has no Houses or Participants assigned yet (”virgin” configuration) or only those Houses and Participants that have, respectively, been dragged to a Course or pinned (“current” configuration) by the user, It then uses a distribution algorithm to assign the remaining Houses to Courses in a way that keeps track of any Preference a House has for catering a Course, the number of Courses a House is willing to cater, and the maximum seating capacity of a House. When that is done, and on a Course-by-Course basis, Participants are picked at random and placed at a Table in a Course in such a way that the Penalty awarded to that Configuration is minimised. When all Participants have been placed, a certain amount of time is spent to investigate whether or not the Configuration can be improved by switching any two Participants, or moving a Participant from one Table to another.
Method 2: maximum number of pre-set placements
The second method is based on Mutually Orthogonal Latin Squares (aka MOLS) and uses as a starting point a Configuration that has a quadratic number of Participants, n2. Under such circumstances it is easy to construct a seating arrangement consisting of m Courses with n Tables per Course in such a way that no two Participants meet more than once (denoted as an “ideal” configuration), provided there exist m-2 MOLS of order n. Note that no such 2 MOLS exist for n=6, implying that it is possible to design an ideal configuration with 3 Courses for 6x6 = 36 Participants that are equally divided over 6 Tables per Course, but it is not possible to do the same thing for 4 Courses.
When the app uses this method, the set of Participants is increased with a number of “dummy Participants” to get the total number of Participants up to a square, n2. Likewise, dummy Houses are added so as to make sure that, for each Course, there are n Houses available. Under these conditions, as many MOLS as possible are created so as to form an ideal configuration for the desired number of Courses. This ideal configuration is used as a starting point. Dummy houses are subsequently removed from the configuration, and their (real) Participants divided among the other Tables, using a similar approach as in Method 1 to ascertain where these real Participants can best be placed. Any dummy Participants left over are discarded. As with Method 1, a certain amount of time is then spent to investigate whether or not the Configuration can be improved by switching any two Participants, or moving a Participant from one Table to another.
Exchange method
There are two ways in which the Planner app tries to find an optimal Configuration (aka Solution, aka Seating Arrangement): method 1 and method 2, as discussed above. Method 2 starts with a so-called ‘ideal’ configuration where no 2 Participants meet each other twice. Such configurations remain ideal when two Participants exchange Tables in every Course under consideration - but not necessarily when they exchange Tables in only 1 Course. The former is denoted as ‘deep exchange’, while the latter is called ‘shallow exchange’. Of course, deep-exchanges require more computational resources, and methods based on those are therefore slower than those based on shallow-exchanges. That said, because multi-meets are typically of the most concern to the user, and because the number of multi-meets doesn’t change under a deep-exchange in an ideal configuration, it may nonetheless be worthwhile to expend the extra computational resources to affect deep-exchanges when configurations have been built using method 2 discussed above. Because of this, this slider allows the user to tweak how many deep-exchanges are attempted relative to the number of shallow-exchanges in trying to optimize a found solution. When the slider is shifted completely to the left, only shallow-exchanges are used; when it’s shifted completely to the right, only deep-exchanges are used. For positions in-between, the app balances the use of the two exchange methods.
House pick criterion
Participants can only be assigned to a Course once Houses have been assigned to cater that Course. This can of course be done by the user, but the App can also auto-generate a distribution of Houses among Courses, honouring the input given by the user (i.e., preferences for certain Houses to cater certain Courses, the maximum capacity of any given House in terms of room and number of Courses it’s willing to cater). The number of possible distributions rapidly explodes with the number of Houses, and the auto-selection process therefore involves a random element. Generally speaking, the Planner continues to assign Houses (when still available) to Courses in a random manner until two criteria are met:
The user-selected requirement can be selected in this setting:
Course to populate first
In many practical situations, Houses show a willingness to cater a Course, but have a preference for which Course that should be. Because a random process is involved when the Planner app tries to find a distribution of Houses among Courses, this may result in not enough Houses being “left over” to cater the least popular Course (i.e, the Course that the smallest number of Houses is willing to cater) simply because the Planner already assigned those willing to cater the Course to a different one. Although, as a rule, the Planner’s algorithms work well when constrained as little a possible, this setting allows the user to force the Planner to first assign Houses to the “least popular” Course. The options are:
Beta: Historic seating arrangements
Upon its first release, the Planner app has built-in Beta functionality to try and deal with Running Dinners that occurred in the past, so as to take into account the fact that, for example, Participants A and B already met each other in last year’s Running Dinner and would like to not meet again in the Dinner this year. Presuming this year’s Participants also took part in last year's Dinner, such a situation for (for example) 3 Courses can be dealt with by attempting to design a Dinner for 6 Courses, whereby the first 3 are pre-populated with the Houses that served the Courses last year, and the Participants that were assigned to these Houses are pinned in place in those Courses. (Note that these conditions can easily be input by way of CSV (see also the pin tutorial and the CSV tutorial on the Tutorials page.) Of course, penalties associated with people meeting each other once during last year’s Dinner and again during this year’s Dinner shouldn’t count as heavily as people meeting each other twice this year. For this reason, the Planner offers all Courses that ‘occurred in the past’ to be assigned a “discount-factor for multi-meet penalties”, thus taking care of this situation. It needs no argument that calculations involving Dinners that occurred in the past become far more computationally intensive. Moreover, since this constitutes Beta functionality, the user is discouraged from trying this. Nonetheless, the Planner does offer the following choices:
When the second option is chosen, the Course Definition screen will allow the user to designate the “timeframe” of each Course (e.g., “now”, “last year”, “2008”, etc), and assign a penalty discount factor to them.