docs/locale/en/LC_MESSAGES/features/draw-generation-bp.po
# SOME DESCRIPTIVE TITLE.
# Copyright (C) 2019, Philip Belesky, Chuan-Zheng Lee
# This file is distributed under the same license as the Tabbycat package.
# FIRST AUTHOR <EMAIL@ADDRESS>, 2019.
#
#, fuzzy
msgid ""
msgstr ""
"Project-Id-Version: Tabbycat 2.3\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2019-12-31 10:38-0400\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=utf-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Generated-By: Babel 2.7.0\n"
#: ../../features/draw-generation-bp.rst:5
msgid "Draw Generation (BP)"
msgstr ""
#: ../../features/draw-generation-bp.rst:7
msgid "The draw generator for British Parliamentary tournaments tries to rotate teams through positions by assigning them positions they've been in less often before the current round."
msgstr ""
#: ../../features/draw-generation-bp.rst:10
msgid "Summary of options"
msgstr ""
#: ../../features/draw-generation-bp.rst:12
msgid "Options are set in the **Configuration** page as described in :ref:`starting a tournament <starting-a-tournament>`. Options in `italics` with an asterisk are not WUDC-compliant. The recommended options are shown in **bold**."
msgstr ""
#: ../../features/draw-generation-bp.rst:19
msgid "Option"
msgstr ""
#: ../../features/draw-generation-bp.rst:20
msgid "Description"
msgstr ""
#: ../../features/draw-generation-bp.rst:21
msgid "Allowable values"
msgstr ""
#: ../../features/draw-generation-bp.rst:22
msgid ":ref:`Pullup distribution <draw-bp-pullup-distribution>`"
msgstr ""
#: ../../features/draw-generation-bp.rst:23
msgid "Where pullup teams get placed"
msgstr ""
#: ../../features/draw-generation-bp.rst:24
msgid "**Anywhere in bracket**"
msgstr ""
#: ../../features/draw-generation-bp.rst:25
msgid "*All in the same room*\\*"
msgstr ""
#: ../../features/draw-generation-bp.rst:26
msgid ":ref:`Position cost <draw-bp-position-cost>`"
msgstr ""
#: ../../features/draw-generation-bp.rst:27
msgid "Which cost function to use to indicate which position profiles are preferred"
msgstr ""
#: ../../features/draw-generation-bp.rst:28
#: ../../features/draw-generation-bp.rst:179
msgid "Simple"
msgstr ""
#: ../../features/draw-generation-bp.rst:29
msgid "**Rényi entropy**"
msgstr ""
#: ../../features/draw-generation-bp.rst:30
#: ../../features/draw-generation-bp.rst:254
msgid "Population variance"
msgstr ""
#: ../../features/draw-generation-bp.rst:31
msgid ":ref:`Rényi order <draw-bp-renyi-order>`"
msgstr ""
#: ../../features/draw-generation-bp.rst:32
msgid "Order of Rényi entropy"
msgstr ""
#: ../../features/draw-generation-bp.rst:33
msgid "Any non-negative number (default: **1**, *i.e.* Shannon entropy)"
msgstr ""
#: ../../features/draw-generation-bp.rst:34
msgid ":ref:`Position cost exponent <draw-bp-position-cost-exponent>`"
msgstr ""
#: ../../features/draw-generation-bp.rst:35
msgid "Degree to which large position imbalances should be prioritised"
msgstr ""
#: ../../features/draw-generation-bp.rst:36
msgid "Any non-negative number (default: **4**)"
msgstr ""
#: ../../features/draw-generation-bp.rst:37
msgid ":ref:`Assignment method <draw-bp-assignment-method>`"
msgstr ""
#: ../../features/draw-generation-bp.rst:38
msgid "Algorithm used to assign positions"
msgstr ""
#: ../../features/draw-generation-bp.rst:39
msgid "*Hungarian*\\*"
msgstr ""
#: ../../features/draw-generation-bp.rst:40
msgid "**Hungarian with preshuffling**"
msgstr ""
#: ../../features/draw-generation-bp.rst:45
msgid "The big picture"
msgstr ""
#: ../../features/draw-generation-bp.rst:47
msgid "To try to achieve position balance, Tabbycat treats the allocation of teams to debates as an `assignment problem <https://en.wikipedia.org/wiki/Assignment_problem>`_. That is, it computes the \"cost\" of assigning each team to each position in each debate, and finds an assignment of all teams to a position in a debate that minimises the total cost (the sum over all teams)."
msgstr ""
#: ../../features/draw-generation-bp.rst:50
msgid "A simple example"
msgstr ""
#: ../../features/draw-generation-bp.rst:52
msgid "Here's a small example, to illustrate the idea. Say you have a tournament with 16 teams, and you're about to draw round 4. There are sixteen \"places\" in the draw: four positions in each of four rooms. Tabbycat calculates the \"cost\" of putting each team in each place, and puts them in a matrix, like this:"
msgstr ""
#: ../../features/draw-generation-bp.rst:61
msgid "Room"
msgstr ""
#: ../../features/draw-generation-bp.rst:61
msgid "Top"
msgstr ""
#: ../../features/draw-generation-bp.rst:61
msgid "Second"
msgstr ""
#: ../../features/draw-generation-bp.rst:61
msgid "Third"
msgstr ""
#: ../../features/draw-generation-bp.rst:61
msgid "Bottom"
msgstr ""
#: ../../features/draw-generation-bp.rst:63
msgid "Position"
msgstr ""
#: ../../features/draw-generation-bp.rst:63
msgid "OG"
msgstr ""
#: ../../features/draw-generation-bp.rst:63
msgid "OO"
msgstr ""
#: ../../features/draw-generation-bp.rst:63
msgid "CG"
msgstr ""
#: ../../features/draw-generation-bp.rst:63
msgid "CO"
msgstr ""
#: ../../features/draw-generation-bp.rst:65
msgid "**A (8)**"
msgstr ""
#: ../../features/draw-generation-bp.rst:65
#: ../../features/draw-generation-bp.rst:67
#: ../../features/draw-generation-bp.rst:69
#: ../../features/draw-generation-bp.rst:71
#: ../../features/draw-generation-bp.rst:73
#: ../../features/draw-generation-bp.rst:75
#: ../../features/draw-generation-bp.rst:77
#: ../../features/draw-generation-bp.rst:79
#: ../../features/draw-generation-bp.rst:81
#: ../../features/draw-generation-bp.rst:83
#: ../../features/draw-generation-bp.rst:85
#: ../../features/draw-generation-bp.rst:87
#: ../../features/draw-generation-bp.rst:89
#: ../../features/draw-generation-bp.rst:91
#: ../../features/draw-generation-bp.rst:93
#: ../../features/draw-generation-bp.rst:95
msgid "16"
msgstr ""
#: ../../features/draw-generation-bp.rst:65
#: ../../features/draw-generation-bp.rst:67
#: ../../features/draw-generation-bp.rst:69
#: ../../features/draw-generation-bp.rst:73
#: ../../features/draw-generation-bp.rst:75
#: ../../features/draw-generation-bp.rst:77
#: ../../features/draw-generation-bp.rst:81
#: ../../features/draw-generation-bp.rst:83
#: ../../features/draw-generation-bp.rst:85
#: ../../features/draw-generation-bp.rst:87
#: ../../features/draw-generation-bp.rst:91
#: ../../features/draw-generation-bp.rst:93
msgid ":q:`0`"
msgstr ""
#: ../../features/draw-generation-bp.rst:65
#: ../../features/draw-generation-bp.rst:67
#: ../../features/draw-generation-bp.rst:69
#: ../../features/draw-generation-bp.rst:71
#: ../../features/draw-generation-bp.rst:73
#: ../../features/draw-generation-bp.rst:75
#: ../../features/draw-generation-bp.rst:77
#: ../../features/draw-generation-bp.rst:79
#: ../../features/draw-generation-bp.rst:81
#: ../../features/draw-generation-bp.rst:83
#: ../../features/draw-generation-bp.rst:85
#: ../../features/draw-generation-bp.rst:87
#: ../../features/draw-generation-bp.rst:89
#: ../../features/draw-generation-bp.rst:91
#: ../../features/draw-generation-bp.rst:93
#: ../../features/draw-generation-bp.rst:95
msgid "∞"
msgstr ""
#: ../../features/draw-generation-bp.rst:67
msgid "**B (7)**"
msgstr ""
#: ../../features/draw-generation-bp.rst:69
msgid "**C (7)**"
msgstr ""
#: ../../features/draw-generation-bp.rst:71
msgid "**D (6)**"
msgstr ""
#: ../../features/draw-generation-bp.rst:71
#: ../../features/draw-generation-bp.rst:73
#: ../../features/draw-generation-bp.rst:75
#: ../../features/draw-generation-bp.rst:79
#: ../../features/draw-generation-bp.rst:85
#: ../../features/draw-generation-bp.rst:87
#: ../../features/draw-generation-bp.rst:89
#: ../../features/draw-generation-bp.rst:91
#: ../../features/draw-generation-bp.rst:95
msgid "0"
msgstr ""
#: ../../features/draw-generation-bp.rst:71
#: ../../features/draw-generation-bp.rst:79
#: ../../features/draw-generation-bp.rst:89
#: ../../features/draw-generation-bp.rst:95
msgid ":q:`16`"
msgstr ""
#: ../../features/draw-generation-bp.rst:73
msgid "**E (6)**"
msgstr ""
#: ../../features/draw-generation-bp.rst:75
msgid "**F (6)**"
msgstr ""
#: ../../features/draw-generation-bp.rst:77
msgid "**G (5)**"
msgstr ""
#: ../../features/draw-generation-bp.rst:79
msgid "**H (5)**"
msgstr ""
#: ../../features/draw-generation-bp.rst:81
msgid "**I (4)**"
msgstr ""
#: ../../features/draw-generation-bp.rst:83
msgid "**J (4)**"
msgstr ""
#: ../../features/draw-generation-bp.rst:85
msgid "**K (3)**"
msgstr ""
#: ../../features/draw-generation-bp.rst:87
msgid "**L (3)**"
msgstr ""
#: ../../features/draw-generation-bp.rst:89
msgid "**M (3)**"
msgstr ""
#: ../../features/draw-generation-bp.rst:91
msgid "**N (3)**"
msgstr ""
#: ../../features/draw-generation-bp.rst:93
msgid "**O (1)**"
msgstr ""
#: ../../features/draw-generation-bp.rst:95
msgid "**P (1)**"
msgstr ""
#: ../../features/draw-generation-bp.rst:98
msgid "Each \"16\" is the cost of putting a team in a position it's seen once; each \"0\" is the cost of putting a team in the position it hasn't. (Details of how this is calculated are :ref:`below <draw-bp-position-cost-section>`.) For example, team A (on 8 points) has been in every position except CO. The ∞'s indicate places where the team isn't allowed to go, because the room isn't in their bracket. For example, the three teams on 6 points (D, E, F) can go in either the top or second room, because any of them can be the pullup team."
msgstr ""
#: ../../features/draw-generation-bp.rst:100
msgid "The algorithm then chooses entries so that one is selected from each row and one is selected from each column, in a way that minimises the sum of the selected entries. In this case, the selected entries are highlighted in blue. For example, the top room comprises teams E (OG), B (OO), C (CG) and A (CO)."
msgstr ""
#: ../../features/draw-generation-bp.rst:102
msgid "Sometimes, particularly in round 4, it simply isn't possible to \"satisfy\" everyone. For example, among the top eight teams, five haven't been in OO, but only two can be accommodated within those brackets. In this case, teams B and G got lucky; there are also many other draws that would have incurred the same total cost."
msgstr ""
#: ../../features/draw-generation-bp.rst:104
msgid "More generally, in most cases, there will be many optimal solutions. To randomise the selection among them, Tabbycat (under default settings) randomly permutes the rows and columns of the matrix before starting the assignment algorithm."
msgstr ""
#: ../../features/draw-generation-bp.rst:107
msgid "Explanations of options"
msgstr ""
#: ../../features/draw-generation-bp.rst:112
msgid "Pullup distribution"
msgstr ""
#: ../../features/draw-generation-bp.rst:114
msgid "If the number of teams in a bracket is not a multiple of four, it pulls up teams from the next bracket down. The pullup distribution then governs how those teams are paired into the upper bracket."
msgstr ""
#: ../../features/draw-generation-bp.rst:116
msgid "The available options are as follows:"
msgstr ""
#: ../../features/draw-generation-bp.rst:120
msgid "**Anywhere in bracket:** The pullup teams are treated as if they were any other team in their new bracket. For example, if there are 17 teams in a 10-point bracket, then the three 9-point teams that get pulled up may be paired anywhere in the 10-point bracket, independently of each other. Chance might put them in the same room, but more likely, they will not all be in the same room, so there will be multiple pullup rooms in the 10-point bracket."
msgstr ""
#: ../../features/draw-generation-bp.rst:122
msgid "**All in the same room:** All of the pullup teams will be paired into the same room. This means that there will be at most one pullup room per bracket, effectively creating an \"intermediate bracket\"."
msgstr ""
#: ../../features/draw-generation-bp.rst:124
msgid "While it can be argued that the `All in the same room` setting is fairer, it is prohibited by the WUDC constitution. If your tournament follows WUDC rules, you cannot use this setting."
msgstr ""
#: ../../features/draw-generation-bp.rst:126
msgid "The teams that get pulled up aren't specifically chosen---they're just assigned as part of the algorithm described :ref:`above <draw-bp-big-picture>`, which optimises for position balance. Tabbycat doesn't support taking anything else into account when choosing pullup teams. (WUDC rules wouldn't allow it, either.)"
msgstr ""
#: ../../features/draw-generation-bp.rst:131
msgid "Position cost options"
msgstr ""
#: ../../features/draw-generation-bp.rst:133
msgid "The `position cost function` is a function that indicates how \"bad\" it would be if a team were to be allocated a certain position (OG, OO, CG, CO) in a debate. When generating a draw, Tabbycat chooses from among the draws that minimise the sum of the position costs for each team."
msgstr ""
#: ../../features/draw-generation-bp.rst:135
msgid "More formally:"
msgstr ""
#: ../../features/draw-generation-bp.rst:139
msgid "A `position history` or just `history` :math:`\\mathbf{h}` is a 4-tuple where each element is the number of times a team has already been in the corresponding position. For example, :math:`\\mathbf{h} = (0, 2, 1, 1)` means that a team has been in OO twice, CG and CO once each, and hasn't been in OG."
msgstr ""
#: ../../features/draw-generation-bp.rst:140
msgid "A cost function :math:`C(\\mathbf{h},s)` is a function specifying how \"bad\" it would be if a team with position history :math:`\\mathbf{h}` were assigned the position :math:`s` in the next round."
msgstr ""
#: ../../features/draw-generation-bp.rst:142
msgid "Tabbycat allows you to choose from a number of different **position cost functions**, as well as a **position cost exponent** :math:`\\beta`. Then, when allocating teams to debates, Tabbycat allocates teams to positions :math:`(s_t, t \\in\\mathcal{T})` to minimise"
msgstr ""
#: ../../features/draw-generation-bp.rst:144
msgid "\\sum_{t \\in \\mathcal{T}} [C(\\mathbf{h}_t,s_t)]^\\beta"
msgstr ""
#: ../../features/draw-generation-bp.rst:148
msgid "where :math:`\\mathcal{T}` is the set of all teams, :math:`\\mathbf{h}_t` is the position history of team :math:`t` and :math:`s_t` is the position to which team :math:`t` would be allocated."
msgstr ""
#: ../../features/draw-generation-bp.rst:153
msgid "Position cost exponent"
msgstr ""
#: ../../features/draw-generation-bp.rst:155
msgid "The **position cost exponent** :math:`\\beta` controls how different teams trade off with each other."
msgstr ""
#: ../../features/draw-generation-bp.rst:159
msgid "The **larger** :math:`\\beta` is, the more concerned it is with preventing *very* bad situations. That is, it will give more teams some slight unevenness in order to prevent one team from getting a `very` uneven history."
msgstr ""
#: ../../features/draw-generation-bp.rst:161
msgid "The **smaller** :math:`\\beta` is, the more concerned it is with preventing *any* unevenness. That is, it will try to keep more teams from being uneven *at all*, at the cost of possibly letting just one team get a very uneven history."
msgstr ""
#: ../../features/draw-generation-bp.rst:163
msgid "At the large extreme, as :math:`\\beta\\rightarrow\\infty`, it will do everything it can to minimise the plight of the *worst-off* team, and it won't care for *any* team other than the worst-off."
msgstr ""
#: ../../features/draw-generation-bp.rst:165
msgid "At the small extreme, as :math:`\\beta\\rightarrow 0`, it will do everything it can to minimise the number of teams with a non-optimal profile---but if it's impossible to protect a team from sub-optimality, it won't care *how* uneven the unlucky team gets."
msgstr ""
#: ../../features/draw-generation-bp.rst:167
msgid "The \"balanced\" approach would be :math:`\\beta = 1`, which just takes the cost function as-is. This doesn't mean that this is the best idea, however---you'd typically want to bias towards preventing very uneven histories a bit more. Most tournaments will probably want :math:`\\beta` to be somewhere between 2 and 5. (Note that :math:`\\beta` need not be an integer.)"
msgstr ""
#: ../../features/draw-generation-bp.rst:172
msgid "Position cost functions"
msgstr ""
#: ../../features/draw-generation-bp.rst:174
msgid "Tabbycat allows you to choose between three position cost functions :math:`C(\\mathbf{h},s)`: **Simple**, **Rényi entropy** and **Population variance**."
msgstr ""
#: ../../features/draw-generation-bp.rst:176
msgid "In the descriptions that follow, :math:`\\mathcal{S} = \\{\\texttt{OG}, \\texttt{OO}, \\texttt{CG}, \\texttt{CO}\\}`, the set of all BP positions."
msgstr ""
#: ../../features/draw-generation-bp.rst:181
msgid "The simple cost function :math:`C_\\textrm{simple}(\\mathbf{h},s)` returns the number of times the team has already been in position :math:`s`, less the number of times the team has been in its least frequent position. That is,"
msgstr ""
#: ../../features/draw-generation-bp.rst:183
msgid "C_\\mathrm{simple}(\\mathbf{h},s) = \\mathbf{h}[s] - \\min_{s' \\in\\mathcal{S}} \\mathbf{h}[s']"
msgstr ""
#: ../../features/draw-generation-bp.rst:187
msgid "where :math:`\\mathbf{h}[s]` is the element of :math:`\\mathbf{h}` corresponding to position :math:`s`."
msgstr ""
#: ../../features/draw-generation-bp.rst:190
msgid "Rényi entropy"
msgstr ""
#: ../../features/draw-generation-bp.rst:192
msgid "Informally speaking, the `Rényi entropy <https://en.wikipedia.org/wiki/R%C3%A9nyi_entropy>`_ is a measure of the diversity of the positions in a team's history. A history consisting only of one position has *low* entropy, while a history that is perfectly evenly distributed has *high* entropy. The **Rényi entropy cost function** reverses this intuition, so that an even hypothetical history has low cost, while an uneven hypothetical history has high cost."
msgstr ""
#: ../../features/draw-generation-bp.rst:194
msgid "The Rényi entropy takes one parameter, known as its *order*, :math:`\\alpha`, which will be further discussed below."
msgstr ""
#: ../../features/draw-generation-bp.rst:196
msgid "More formally, the Rényi entropy cost function :math:`C_\\textrm{R\\'enyi}(\\mathbf{h},s)` is defined as"
msgstr ""
#: ../../features/draw-generation-bp.rst:198
msgid "C_\\textrm{R\\'enyi}(\\mathbf{h},s) = n_\\mathbf{h} [2 - H_\\alpha(\\hat{p}_{\\mathbf{h},s})]"
msgstr ""
#: ../../features/draw-generation-bp.rst:202
msgid "where"
msgstr ""
#: ../../features/draw-generation-bp.rst:206
msgid ":math:`n_\\mathbf{h} = \\sum_{s'} \\mathbf{h}[s']` is the number of rounds the team has competed in so far."
msgstr ""
#: ../../features/draw-generation-bp.rst:207
msgid ":math:`\\hat{p}_{\\mathbf{h},s}` is the *normalised hypothetical* position history that would arise if a team with history :math:`\\mathbf{h}` were to be allocated position :math:`s` in the next round; that is,"
msgstr ""
#: ../../features/draw-generation-bp.rst:209
msgid "\\hat{p}_{\\mathbf{h},s}[s'] = \\begin{cases} \\frac{1}{n_\\mathbf{h} + 1} (\\mathbf{h}[s'] + 1), &\\text{ if } s = s', \\\\ \\frac{1}{n_\\mathbf{h} + 1} \\mathbf{h}[s'], &\\text{ if } s \\ne s'. \\end{cases}"
msgstr ""
#: ../../features/draw-generation-bp.rst:216
msgid "Note that :math:`\\hat{p}_{\\mathbf{h},s}` is a probability distribution (that is, its elements sum to 1)."
msgstr ""
#: ../../features/draw-generation-bp.rst:218
msgid ":math:`H_\\alpha(\\cdot)` is the `Rényi entropy <https://en.wikipedia.org/wiki/R%C3%A9nyi_entropy>`_ of order :math:`\\alpha` of a probability distribution, defined as"
msgstr ""
#: ../../features/draw-generation-bp.rst:220
msgid "H_\\alpha(p) = \\frac{1}{1-\\alpha} \\log_2 \\left( \\sum_{s\\in\\mathcal{S}} (p[s])^\\alpha \\right), \\qquad \\alpha \\ne 1."
msgstr ""
#: ../../features/draw-generation-bp.rst:224
msgid "In the special (limiting) case where :math:`\\alpha=1`, it reduces to the `Shannon entropy <https://en.wikipedia.org/wiki/Shannon_entropy>`_,"
msgstr ""
#: ../../features/draw-generation-bp.rst:226
msgid "H_1(p) =-\\sum_{s\\in\\mathcal{S}} p[s] \\log_2 p[s]."
msgstr ""
#: ../../features/draw-generation-bp.rst:230
msgid "Note that for all :math:`\\alpha`, :math:`0 \\le H_\\alpha(p) \\le \\log_2(4) = 2` (since there are four positions in BP)."
msgstr ""
#: ../../features/draw-generation-bp.rst:234
msgid "The **Rényi order** is the parameter :math:`\\alpha` above, and it controls *what it means to be \"even among positions\"* for a team. Note that \"evenness\" is not easily defined. After round 8, which position history is more even: (0, 2, 3, 3) or (1, 1, 1, 5)? The Rényi order allows us to tune this definition."
msgstr ""
#: ../../features/draw-generation-bp.rst:238
msgid "The **smaller** :math:`\\alpha` is, the more it cares that teams compete in every position *at least* once, favouring (1, 1, 1, 5) over (0, 2, 3, 3): it's worse to have never OGed, than it is to have COed five times."
msgstr ""
#: ../../features/draw-generation-bp.rst:240
msgid "The **larger** :math:`\\alpha` is, the more it cares that teams do not compete in *any* (one) position too many times, favouring (0, 2, 3, 3) over (1, 1, 1, 5): it's worse to have COed five times, than it is to have never OGed."
msgstr ""
#: ../../features/draw-generation-bp.rst:242
msgid "At the small extreme, as :math:`\\alpha\\rightarrow0`, it *only* counts how many positions a team has seen at least once, and doesn't care about the distribution among them so long as a team has been in each position once."
msgstr ""
#: ../../features/draw-generation-bp.rst:244
msgid "At the large extreme, as :math:`\\alpha\\rightarrow\\infty`, it *only* looks at how many times each team has seen its *most frequent* position, and tries to keep this number even among all teams."
msgstr ""
#: ../../features/draw-generation-bp.rst:246
msgid "The \"balanced\" approach would be :math:`\\alpha=1` (the `Shannon entropy <https://en.wikipedia.org/wiki/Shannon_entropy>`_), though of course it's arguable what \"balanced\" means. Tabbycat defaults to this value."
msgstr ""
#: ../../features/draw-generation-bp.rst:248
msgid "To give some intuition for the useful range: In round 9, a strict ordering by number of positions seen at least once occurs for approximately :math:`\\alpha < 0.742`. A strict ordering by number of times in the most frequent position occurs for :math:`\\alpha>3`. Changing :math:`\\alpha` outside the range :math:`[0.742, 3]` will still affect the relative (cardinal) weighting *between teams*, but will not affect the *ordinal* ranking of possible histories."
msgstr ""
#: ../../features/draw-generation-bp.rst:250
msgid "The purpose of weighting costs by :math:`n_\\mathbf{h}` is to prioritise those teams who have competed in every round over those who have competed in fewer rounds."
msgstr ""
#: ../../features/draw-generation-bp.rst:256
msgid "The **population variance** cost function is just the population variance of the history 4-tuple,"
msgstr ""
#: ../../features/draw-generation-bp.rst:258
msgid "C_\\textrm{popvar}(\\mathbf{h},s) = \\frac14 \\sum_{s'\\in\\mathcal{S}} \\left(\\mathbf{\\hat{h}}_s[s'] - \\mu_{\\mathbf{\\hat{h}}_s} \\right)^2,"
msgstr ""
#: ../../features/draw-generation-bp.rst:262
msgid "where :math:`\\mathbf{\\hat{h}}_s` is the *hypothetical* position history that would arise if a team with history :math:`\\mathbf{h}` were to be allocated position :math:`s` in the next round; that is,"
msgstr ""
#: ../../features/draw-generation-bp.rst:264
msgid "\\mathbf{\\hat{h}}_s[s'] = \\begin{cases} \\mathbf{h}[s'] + 1, &\\text{ if } s = s', \\\\ \\mathbf{h}[s'], &\\text{ if } s \\ne s'. \\end{cases}"
msgstr ""
#: ../../features/draw-generation-bp.rst:271
msgid "and where :math:`\\mu_{\\mathbf{\\hat{h}}_s}` is the mean of :math:`\\mathbf{\\hat{h}}_s`,"
msgstr ""
#: ../../features/draw-generation-bp.rst:273
msgid "\\mu_{\\mathbf{\\hat{h}}_s} = \\frac14 \\sum_{s'\\in\\mathcal{S}} \\mathbf{\\hat{h}}_s[s']."
msgstr ""
#: ../../features/draw-generation-bp.rst:277
msgid "At the extremes, a team that has seen all positions evenly will have a population variance of zero, while a team that has seen just one position :math:`n` times will have a population variance of :math:`\\frac{3n^2}{16}`."
msgstr ""
#: ../../features/draw-generation-bp.rst:282
msgid "Assignment method"
msgstr ""
#: ../../features/draw-generation-bp.rst:284
msgid "Tabbycat uses the `Hungarian algorithm <https://en.wikipedia.org/wiki/Hungarian_algorithm>`_ to solve the `assignment problem <https://en.wikipedia.org/wiki/Assignment_problem>`_ of assigning teams to positions in debates. This can be run with or without preshuffling:"
msgstr ""
#: ../../features/draw-generation-bp.rst:288
msgid "**Hungarian algorithm** just runs the Hungarian algorithm as-is, with no randomness. This probably isn't what you want."
msgstr ""
#: ../../features/draw-generation-bp.rst:290
msgid "**Hungarian algorithm with preshuffling** also runs the Hungarian algorithm on the position cost matrix, but shuffles the input so that the draw is randomised, subject to having optimal position allocations."
msgstr ""
#: ../../features/draw-generation-bp.rst:292
msgid "Preshuffling doesn't compromise the optimality of position allocations: It simply shuffles the order in which teams and debates appear in the input to the algorithm, by randomly permuting the rows and columns of the position cost matrix. The Hungarian algorithm still guarantees an optimal position assignment, according to the chosen position cost function."
msgstr ""
#: ../../features/draw-generation-bp.rst:294
msgid "Running the Hungarian algorithm *without* preshuffling has the side effect of grouping teams with similar speaker scores in to the same room, and is therefore prohibited by WUDC rules. Its inclusion as an option is mainly academic; most tournaments will not want to use it in practice."
msgstr ""
#: ../../features/draw-generation-bp.rst:296
msgid "No other assignment methods are currently supported. For example, Tabbycat can't run fold (high-low) or adjacent (high-high) pairing *within* brackets."
msgstr ""