Journal Pre-proofs Improving solution times for stable matching problems through preprocessing

We present new theory, heuristics, and algorithms for preprocessing instances of the Stable Marriage problem with Ties and Incomplete lists (SMTI) and the Hospitals/Residents problem with Ties (HRT). Instances of these problems can be preprocessed by removing from the preference lists of some agents entries such that the set of stable matchings is not aﬀected. Removing such entries reduces the problem size, creating smaller models that can be more easily solved by integer programming (IP) solvers. The new theorems are the ﬁrst to describe when preference list entries can be removed from instances of HRT when ties are present on both sides, and also extend existing results on preprocessing instances of SMTI. A number of heuristics, as well as an IP model and a graph-based algorithm, are presented to ﬁnd and perform this preprocessing. Experimental results show that our new graph-based algorithm achieves a 44% reduction in the average running time to ﬁnd a maximum weight stable matching in real-world instances of SMTI compared to existing preprocessing techniques, and 80% compared to not using preprocessing. We also show that, when solving MAX-HRT instances with ties on both sides, our new techniques can reduce runtimes by up to 55%.


Introduction
Stable matching problems consist of some set (or sets) of agents where each agent ranks a subset of the other agents in order of preference. The solution to such a problem is a stable pairing of agents, or a stable matching. Gale and Shapley introduced the notion of stability, as well as the Stable Marriage (SM) problem, in their seminal paper [9], along with a polynomial-time algorithm to solve SM. An instance of SM consists of 2n agents split into equal-sized sets called men and women, where each woman ranks all men (and none of the women) in strict order of preference, and vice-versa. Each man and woman must be paired up (with a woman and man respectively) into a stable matching. A matching is stable if there are no two people not currently matched together who would prefer to be matched with each other over their current partner. Two such people are said to block the matching -they are a blocking pair.
In the same paper [9], Gale and Shapley also introduced the College Admissions problem that models the problem of allocating students to positions at colleges. This is a stable matching problem similar to SM, except that while each student can be assigned to at most one college, each college has some positive integral capacity q such that they can be matched to at most q students. Additionally, students may find some colleges completely unacceptable, so instead students only rank their acceptable colleges in strict order.

Preprocessing stable matching problems
While Gale and Shapley's original algorithm [9] does find a stable matching in polynomial time, an extended version [11] removes from the problem preference list entries that will not affect the outcome of the algorithm. Even though stable matching problems like MAX-SMTI and MAX-HRT are often solved with IP models, and not the algorithm of Gale and Shapley, the idea of removing preference list entries to simplify such problems can still be advantageous. Removing preference list entries without modifying the set of stable matchings shortens preference lists, in turn reducing the size of the models and thus solution times [8]. This removal of preferences is done before building the IP model, and so it is called preprocessing.
Preprocessing can be performed using variations of the Gale-Shapley algorithm, wherein agents "propose" in rounds, and based upon the outcomes of such proposals certain pairs may be removed. Such a technique is known for instances of SMTI where preferences on one side have length at most two [15]. A similar technique has also been applied to HRT [14] for no restriction on the lengths of the preference lists, namely "Hospitalsoffer" and "Residents-apply". However, these require that the preference lists of the residents be strictly ordered (i.e., contain no ties), while the hospitals may have ties in their preference lists. Preprocessing theory for instances with ties on both sides has recently been introduced for SMTI [8], which we expand upon, and also extend to HRT. In this theory, pairs that can be removed are identified by considering a given agent in a stable matching problem, a set of positions they wish to be matched to, and the potential competition the agent may face for these positions. If the number of positions is greater than the number of competitors for these positions, then in any stable matching the given agent cannot be assigned to a position worse than the given set, and so any worse preferences from the agent can be removed. The same paper also defines a simple preprocessing heuristic (which we describe in Section 3.1.1) to detect such sets, and uses this heuristic to gain significant improvements in overall solution times on various families of MAX-SMTI instances, both randomly-generated and application-specific.

Our contribution
In this paper, we extend the theory behind preprocessing to identify more preference list entries that can be removed from instances of SMTI without affecting any stable matching. This theory is also extended to HRT, where existing techniques only worked when one set of agents (the doctors) had strict preferences, while our new techniques apply when both doctors and hospitals may express ties. A number of new heuristics are given that find a subset of the preference list entries that can be removed, as well as a polynomial-time algorithm that finds all the entries in preference lists that can be removed by preprocessing according to our extended theory. Experimental results show that the average time to solve real-world MAX-WT-SMTI-GRP instances from Coram is reduced from 149 seconds using existing preprocessing techniques to only 83 seconds using our new graph-based algorithms. The number of preference list entries removed according to our new theory is increased by approximately 82%, compared to existing preprocessing techniques, contributing to this reduced runtime. We demonstrate similar results in randomly-generated instances of MAX-WT-SMTI-GRP. This increase in the number of preference list entries removed is also shown in the randomly-generated MAX-WT-SMTI-GRP instances with a similar size, where the average number of entries removed increases from 83093 to 185437.
For MAX-SMTI problems, we investigate the effect that the length of preference lists can have on the usefulness of preprocessing. When all candidates have preference lists with 3 entries, relatively few entries can be removed via preprocessing, and we show that using more complex preprocessing techniques can, at times, be detrimental. If the candidates have preference lists with 5 entries, we show that preprocessing is useful, with a reduction from 478 seconds without preprocessing to 437 with heuristic preprocessing. When the preference list of each candidate has 10 entries, however, we show that it is more useful to introduce dummy variables [8], and once such variables are introduced, preprocessing is again less effective. When these dummy variables are present, preprocessing becomes useful when candidates have preference lists that contain a sizeable proportion of the positions. We show that with 250 agents, preprocessing begins to have an effect when preference lists of the candidates have 100 entries, and becomes more significant as longer preference lists are used. When candidate preference lists have 200 entries, we see that total runtime (preprocessing and solving) is reduced from 138 seconds using no preprocessing, or 128 seconds using existing preprocessing, to 102 seconds using our new heuristics.
We also experimentally study instances of HRT. In instances where only the hospitals may have ties in their preference lists, we report that preprocessing is rarely relevant, and that existing techniques "Hospitalsoffer" and "Residents-apply" [14] are still suitable. However, when ties are present in both sides, we are able to show a 24% to 55% improvement in runtime on instances with up to 4000 doctors, as well as solving 118 of 120 instances with 8000 doctors compared to 112 with existing techniques.

Paper layout
Section 2 introduces some of the background, as well as both existing theory and our new theory to detect more preprocessing opportunities, and the extension of this theory to HRT. An exact algorithm, an IP model, and several heuristics for finding preprocessing opportunities are given in Section 3. Section 4 describes the results of the experiments carried out to compare these approaches, and our conclusion follows in Section 5.

Background and preprocessing theory
Section 2.1 gives notation and definitions for the stable matching problems we study. Section 2.2 then describes some of the known preprocessing techniques in the literature. Section 2.3 theoretically identifies more preprocessing that can be performed, and Section 2.4 then extends these results to stable matching problems with capacities.

Definitions and notation
We begin by defining the Workers / Firms problem with Ties (WFT), as the Hospital / Residents problem with Ties (HRT) and the Stable Marriage problem with Ties and Incomplete Lists (SMTI) are specialisations of WFT.
An instance I of WFT consists of two sets of agents, which we call positions (P ) and candidates (C). We denote their sizes as n p = |P | and n c = |C|. We use the terms positions and candidates specifically because our preprocessing is easier to explain when we mentally separate the two sets of agents into distinct types. However, they are still symmetrically equivalent, so any preprocessing technique applied to candidates can also be applied to positions and vice-versa.
Each position (respectively candidate) finds some or all of the candidates (respectively positions) acceptable, and ranks these candidates (respectively positions) in non-increasing order of preference. These preferences may include ties, where an agent is indifferent between two or more options. In this paper we assume that if a position p finds a candidate c acceptable, then candidate c also finds p acceptable, and we will say that the pair (c, p) is acceptable. If a candidate c strictly prefers p 1 over p 2 , we will write p 1 ≺ c p 2 . If c either prefers p 1 over p 2 or is indifferent between the two, we write p 1 c p 2 . Each individual candidate c and position p also has some positive integral capacity (or quota), denoted q c and q p , respectively.
A matching M in an instance of WFT is a subset of C × P such that each candidate c (respectively position p) occurs in at most q c (respectively q p ) pairs, and every (c, p) ∈ M is acceptable. We will write M (p) for the set of candidates matched with p in M (i.e., M (p) = {c | (c, p) ∈ M }), and we will write M (c) for the set of positions matched with c in M (i.e., M (c) = {p | (c, p) ∈ M }). In a given matching, if a candidate c (respectively position p) occurs in exactly q c (respectively q p ) pairs, we say they are full. Otherwise, we say they are undersubscribed. Additionally, if a candidate or position occurs in exactly 0 pairs, we say they are empty. A candidate or position who is empty is simultaneously undersubscribed. • either p is undersubscribed, or there is some c ′ ∈ M (p) such that c ≺ p c ′ (i.e., p strictly prefers c to one of their currently assigned candidates), and • either c is undersubscribed, or there is some p ′ ∈ M (c) such that p ≺ c p ′ (i.e., c strictly prefers p to one of their currently assigned positions).
A matching with no blocking pairs is called stable.
HRT is the restriction of WFT where one set of agents (either all candidates, or all positions) have unitary capacity, and SMTI is the restriction of WFT where all candidates and all positions have unitary capacity.
Example 1 gives a sample of the notation used to describe the preferences of agents in individual instances of SMTI, HRT, and WFT. Each agent is identified, and then followed by its preferences in descending order such that if p 1 comes before p 3 , then p 1 is preferred over p 3 . A tie in candidate c's preference list is a group of positions that candidate c does not distinguish between. We will say that c ranks p 1 at the same level or better than p 2 if both p 1 and p 2 appear in the preference list of c, and if either p 1 and p 2 appear in the same tie group, or c prefers p 1 to p 2 . As seen in Example 1, we write [p 2 p 3 ] in the preference list of candidate c 1 if candidate c 1 is indifferent between p 2 and p 3 . Such a tie has length 2. Note that in a given preference list, if a position is not tied with any other position, such as the position p 1 in the preference list of c 1 , we can refer to this as a tie of length 1. We define the rank of either an element of a preference list, or a tie within a preference list, as one plus the number of ties that are strictly preferred to it. Adding one allows the natural expression "first tie " to refer to the tie with rank 1.
Example 1. The following is an example of preference lists as expressed by two candidates and three positions.

Existing preprocessing theory for SMTI
An instance I of a stable matching problem is preprocessed by removing entries from preference lists such that p is removed from the preference list of c only if the pair (c, p) appears in no stable matching of I, and removing (c, p) does not create any new stable matchings. The removal of these preference list entries can, as demonstrated in Section 4, have a significant effect on the time taken to find either maximum cardinality stable matchings, or maximum weight stable matchings. Note that this preprocessing is not dependent on the specific stable matching problem being solved. Our preprocessing applies to any problem that searches for one or more stable matchings satisfying some criteria, as it does not remove any existing stable matching nor introduce any new stable matching. This includes the common problem of finding a largest stable matching, but also searches for egalitarian stable matchings, or even the problem of counting the number of stable matchings [22].
Under certain variations of stable matching problems, the existence of a stable matching is not guaranteed (see e.g., [16,17,18]). In an instance of a stable matching problem with no stable matchings, each acceptable pair vacuously is in no stable matching, and so removing some preference list entries corresponding to pairs that are not in any stable matching may inadvertently create a new instance that does contain a stable matching. However, even if an instance of a stable matching problem does admit some stable matchings, not all pairs that appear in no stable matching can be removed without creating new stable matchings, as seen in Example 2.
Example 2. Consider the following instance of SMTI.
It is routine to check that there is no stable matching that contains (c 1 , p 1 ). To see this, if (c 1 , p 1 ) is in a stable matching, then the stable matching must also contain (c 2 , p 4 ) as otherwise (c 2 , p 1 ) forms a blocking pair. Then, to ensure that (c 4 , p 4 ) is not blocking, the stable matching must contain (c 4 , p 1 ), a contradiction as the stable matching already contains (c 1 , p 1 ). At the same time, however, the only pair that blocks the matching The following theorem is a restatement of Theorem 1 in [8] 1 .
Theorem 1 (Theorem 1 in [8]). Let I be an instance of SMTI. Consider a candidate c and a non-empty set of positions P such that for every position p ∈ P, (c, p) is an acceptable pair. Let C be the set of candidates that at least one position in P ranks at the same level or better than c, i.e., C = {c ′ | ∃ p ∈ P s.t. c ′ p c}. If |P| ≥ |C|, then in any stable matching M , candidate c will be allocated a position p ′ such that p ′ c p for at least one p ∈ P.
The gist of this theorem is that for candidate c, P is some set of positions that c finds acceptable and C contains c's competition for these (i.e., any candidate who could match with a position p ∈ P such that (c, p) would not be a blocking pair). If C is small enough compared to P, then candidates in C (excluding c) cannot possibly take all positions in P. As a result, in any stable matching c must be matched with some position that is no worse than what c considers to be the worst position in P .

Identifying additional preprocessing in SMTI
We can extend Theorem 1 as follows: Theorem 2. Let I be an instance of SMTI. Let us consider a candidate c, a non-empty set of positions P such that for every position p ∈ P the pair (c, p) is an acceptable pair and a set of positions P ′ such that for any p ′ ∈ P ′ 1. the pair (c, p ′ ) is not an acceptable pair, and 2. in any stable matching of I, p ′ will be assigned to some candidate (i.e., p ′ will not be unassigned).
Let C be the set of all candidates c ′ that either: Criterion 1: at least one position in P ranks c ′ at the same level or better than c, i.e., or Criterion 2: at least one position in P ′ finds c ′ acceptable holds. If |P| + |P ′ | ≥ |C|, then in any stable matching M , candidate c will be allocated a position p ⋆ such that p ⋆ c p for at least one p ∈ P.
This theorem is a specialisation of Theorem 3, and so we skip the proof. Instead, we refer the reader to the upcoming proof of the latter. Note that Criterion 1 in Theorem 2 does mean that c ∈ C.
In this theorem the set P ′ can contain positions that definitely will be filled, but not by c. These positions can, however, "use up" candidates that are in C, meaning those candidates can no longer take positions in P. This might result in there not being enough other candidates to fill positions in P. Therefore, in a stable matching c cannot be matched with any position it considers worse than all positions in P.
We have not yet indicated how to select P or P ′ . Indeed, we demonstrate several methods for determining both P and P ′ in Section 3. Given appropriate sets P and P ′ , Example 3 demonstrates how C is determined and used to decide whether preprocessing is possible.
Example 3 (Example of use of Theorem 2). Consider an instance of SMTI with n c = 3 and n p = 4 (i.e., there are 3 candidates and 4 positions). We will preprocess the preference list for c 3 . The relevant preferences are as follows: We begin by noting that the first choice for p 1 is c 1 , and vice-versa. So, in any stable matching, p 1 will always be assigned to some candidate (we will use this fact in order to apply Theorem 2). Indeed, we could continue in such a manner to find the unique stable matching in this instance, but we do not proceed in this manner as our aim is to demonstrate the usage of Theorem 2.
Firstly, consider P = {p 2 , p 3 }. Looking at the preferences of p 2 and p 3 , we see that C must contain c 1 , c 2 , and c 3 , as these are the candidates that at least one of p 2 or p 3 consider to be at least as good as c 3 . This means that |C| > |P|, and so we cannot preprocess.
However, we also know that c 3 does not find p 1 acceptable, and that p 1 will always be matched to some candidate. So we can also consider P ′ = {p 1 }. Since the preference list of p 1 contains the candidates c 1 and c 2 , we must add both of these to C, but they are already present so there is no change to C. Now we have |C| = |P| + |P ′ |, and so we can remove from the preference list of c 3 any preferences worse than the worst position in P. That is, we remove the position p 4 from the preference list of c 3 (and remove c 3 from the preference list of p 4 ).
We can reason through this process as well as follows. If c 3 is not matched to p 2 , then p 2 must be matched to either c 1 or c 2 . If, in addition to this, c 3 is also not matched to p 3 , then p 3 must be matched to c 2 . This means that p 2 must be matched to c 1 . However, since p 1 must be matched to some candidate, this is a contradiction, as p 1 only finds c 1 or c 2 acceptable. Therefore, c 3 must be matched to one of p 2 or p 3 .

Extending preprocessing to HRT
We extend the above preprocessing results to HRT now. Recall that in HRT, doctors have unitary capacity while hospitals have positive integral capacities. To preprocess a hospital's preference list, we must consider the hospitals as candidates, and must therefore allow all candidates to have positive integral capacities. However, to preprocess a doctor's preference list we must consider the doctors as candidates, and must therefore allow all positions to have positive integral capacities. Thus we must allow positions to refer to either hospitals or doctors, and similarly for candidates. Our general framework will, therefore, allow for positive integral capacities in all positions and candidates, but with the caveat that either all positions have unitary capacity, or all candidates have unitary capacity. This allows us to prove the correctness of preprocessing HRT in one theorem. We later give an example demonstrating that this preprocessing does not immediately extended to instances of WFT.
Our theorem for HRT replaces the sizes of the sets C, P, and P ′ with the sums of the capacities of each in the criteria for preprocessing. Let A be some set of agents, and let q a be the capacity (quota) of agent a. We will then write |A| q to mean a∈A q a .
Theorem 3. Let I be an instance of HRT (i.e., either the candidates have unitary capacity and positions have positive integral capacities, or vice-versa). Let us consider a candidate c, a non-empty set of positions P such that for every position p ∈ P, (c, p) is an acceptable pair, a set of positions P ′ such that for any p ′ ∈ P ′ , (c, p ′ ) is not an acceptable pair and in any stable matching of I p ′ will not be undersubscribed. Let C be the set of all candidates c ′ that either: Criterion 1: at least one position in P ranks at the same level or better than c, i.e., or Criterion 2: at least one position in P ′ finds acceptable.
If |P| q + |P ′ | q ≥ |C| q , then in any stable matching M , candidate c will be full and will only be allocated positions p ⋆ such that p ⋆ c p for at least one p ∈ P. Proof. Let I, M , c, P, P ′ , and C be as given in the theorem, and assume towards a contradiction that either c is undersubscribed or c is assigned at least one position p + such that p ≺ c p + for all p ∈ P.
By the definition, we know that c ∈ C. Since c is either undersubscribed, or not assigned to only positions p ∈ P, and since |P| q +|P ′ | q > |C| q −1, and as every p ′ ∈ P ′ will be assigned to capacity with only candidates c ′ ∈ C, by the pigeon hole principle there must be some p ∈ P that is either undersubscribed or full and assigned some candidate c + ∈ C.
We will now show that (c, p) forms a blocking pair. If p is undersubscribed then p would prefer to be assigned to c, and if p is full, then by construction p prefers c to c + (otherwise c + would be in C). Similarly, if c is undersubscribed then c would prefer to be assigned p, and if c is full then c is assigned p + , and, as p ′ ≺ c p + for all p ′ ∈ P, then c prefers p to p + .
Lastly, we need to show that (c, p) ∈ M . To do this, we rely on the fact that either c or p must have unitary capacity. We know that p is either undersubscribed, or assigned some candidate c + = c, so if p has unitary capacity, then (c, p) ∈ M . Similarly, we know that c is either undersubscribed, or assigned some p + = p, and so if c has unitary capacity, then (c, p) ∈ M .
Thus, as either p or c must have unitary capacity, (c, p) ∈ M , and so (c, p) will form a blocking pair.
As in Theorem 2, Criterion 1 in Theorem 3 means that c ∈ C. Note that if we allow both candidates and positions in Theorem 3 to have positive integral capacities, we may reach a scenario in which both c and p are undersubscribed or prefer each other to one of their currently assigned partners, even though (c, p) is already in the matching, and so would not form a blocking pair. Example 4 demonstrates such a scenario.
Example 4. Consider the following instance I of WFT which contains one candidate and two positions, wherein c 1 has a capacity of three, p 1 also has a capacity of three, and p 2 has a capacity of one.
Clearly the only stable matching is {(c 1 , p 1 ), (c 1 , p 2 )}, but if we preprocess the preference list of p 1 with P = {p 1 }, then C = {c 1 }, and we determine that |P| q = |C| q . Thus, if the restriction in Theorem 3 that ensures either all candidates or all positions have unitary capacity were to be dropped, the pair (c 1 , p 2 ) would incorrectly be removed from I. We note that if a pair can appear multiple times in a "matching", then this preprocessing theory would apply in an obvious manner.
Given an instance I of HRT, a candidate c and sets P and P ′ that satisfy Theorem 2, our preprocessing creates a new instance I ′ by removing from the preference list of c any positions that c considers strictly worse than all of those in P. It is trivial to see that any stable matching that exists in I must also exist and be stable in I ′ , but the opposite is not as clear. We will show such a result for WFT, which is more general than either HRT or SMTI. To prove our result, we first need the following lemma.
Lemma 4. Let I be an instance of WFT, let c be some candidate such that in any stable matching in I, c is always full, let P be some set of positions such that if c is assigned to p in some stable matching of I then p is in P, and let I ′ be the instance of WFT created from I by marking as unacceptable to c any position p + that satisfies p ≺ c p + for all p ∈ P. Then in any matching M that is stable in I ′ , c is full.
With this lemma, which we prove in Appendix A, we can now show that our preprocessing is correct.
Theorem 5. Let I be an instance of WFT, let c be some candidate such that in any stable matching in I, c is always full, let P be some set of positions such that if c is assigned to p in some stable matching of I then p is in P, and let I ′ be the instance of WFT created from I by marking as unacceptable to c any position p + that satisfies p ≺ c p + for all p ∈ P. Then any matching M that is stable in I ′ is also stable in I.
Proof. Assume towards a contradiction that there is a matching M that is stable in I ′ but not stable in I. By Lemma 4 we know that c must be full in M . As M is not stable in I, there must be some pair (c + , p + ) that blocks M in I but not in I ′ . Such a pair must be a pair that was marked as unacceptable when constructing I ′ , and therefore c + = c.
As c is full in M , let p ⋆ ∈ M (c) be a position that satisfies p + ≺ c p ⋆ . Such a p ⋆ must exist for (c, p + ) to block M in I. However, as p ⋆ ∈ M (c), p ⋆ was not marked as unacceptable to c when constructing I ′ and so there must be some p ′ ∈ P such that p ⋆ c p ′ . As p ′ ∈ P, we also have p ′ ≺ c p + , which gives us Example 5 demonstrates that Theorem 3 is more powerful than "Hospitals-offer" and "Residentsapply" [14], the existing preprocessing algorithms for HRT. Example 5. This example demonstrates how Theorem 3 can detect preprocessing that is possible in an instance of HRT that "Hospitals-offer" and "Residents-apply" [14] are unable to detect. We use p to denote the hospitals and c to denote the resident for consistency with the theory. In this example, p 1 has capacity 1, p 2 has capacity 1, and p 3 has capacity 2.
It is routine to check that neither of "Hospitals-offer" and "Residents-apply" [14] can remove any preference list entries. However we can preprocess the preference list of c 1 by letting P = {p 2 , p 3 }. Then C = {c 1 , c 2 , c 3 }, and as q p2 = 1 and q p3 = 2, |P| q = 3 ≥ 3 = |C| q . This results in the removal of the entry p 1 from the preference list of c 1 . This same result is trivially reasoned by realising that: • p 2 and p 3 both find all three doctors acceptable, • together p 2 and p 3 have the capacity to accept all three doctors, • all three doctors find both p 2 or p 3 acceptable, and • no doctor prefers p 1 over either of p 2 or p 3 .

Algorithms for carrying out preprocessing
This section describes a number of ways in which instances of stable matching problems can be preprocessed. As a reminder to the reader, preprocessing is not only useful when searching for a largest stable matching: it can be applied to any problem that searches for stable matchings, including different types of optimality conditions such as egalitarian or minimum-regret, and the problem of counting the number of stable matchings [22].
Preprocessing a preference list in a stable matching problem is possible if a set P can be found that satisfies Theorem 1, and further preprocessing can be carried out by identifying sets P and P ′ that satisfy Theorem 3. In Section 3.1 we give a number of new heuristics for finding such sets P, and Section 3.2 defines an ILP model to find sets P and P ′ . Section 3.3 gives a graph-based representation of preprocessing, along with the proofs demonstrating the equivalence between the graph-based representation and the theory in Section 2. This graph-based representation is used in Section 3.4 to construct two polynomial-time algorithms to identify preprocessing. Lastly, Section 3.5 gives a brief discussion on the application of preprocessing techniques on instances of stable matching problems, rather than on a single preference list.

Heuristics
We will now define a number of heuristics which can identify sets P that allow preprocessing according to Theorem 1. While the first heuristic defined in Section 3.1.1 was known in the literature [8] for SMTI, Theorem 3 allows us to extend it to HRT. All other heuristics are new contributions.
Our experimental results show that while heuristics are not guaranteed to find a maximal reduction in the lengths of the preference lists, they can still reduce the solution time of the IP models. We show in Section 4 that the trade-off between preprocessing time and solution time means that, for some scenarios, these heuristics are preferable over more complex methods that take longer to compute.
We note that while our new theory involves sets P and P ′ , by definition when preprocessing a candidate c only positions that c does not find acceptable might end up in P ′ . As such, it is not clear how a suitable set P ′ could be easily determined, and as a result, we were unable to construct any useful heuristic that also searched for P ′ .
We now present our three heuristics for preprocessing.

Descending order of preference
Given a candidate c with preference list L, the most obvious heuristic for finding a suitable P is to simply add to P positions p from L in descending order of preference. If, at any point in this process Theorem 1 is satisfied, then preprocessing can occur. This was described in [8], and was shown to be implementable in O((n c + n p )n p ) time for a given candidate in an instance of SMTI.
In our research into preprocessing, we noted that the implementation used in [8] could be improved by using a data structure with constant time lookup for storing P. This has no effect on the asymptotic analysis, but we found it to have significantly improved performance under certain scenarios, which is reported in Section 4.

Skip larger
When using the heuristic of Section 3.1.1, there are some positions p that, when added to P, cause a large increase to |C| q . To avoid such issues, these particular positions p that cause a large increase to |C| q can simply be skipped. We implement three such heuristics, which do not add a position p to P, but instead skip over it, if adding p to P would cause |C| q to increase by at least 5, 15, or 50 candidates, respectively. Note that with this terminology, the "descending" heuristic introduced in Section 3.1.1 can also be termed Skip-∞. This will prove useful when discussing the results of our computational experiments.

FindBest
As Theorem 3 requires that |C| q be smaller than or equal to |P| q + |P ′ | q , it seems reasonable to add to P a position p that increases |C| q by the smallest amount possible. Finding such a p is possible by calculating the change in |C| q for each position p that has not yet been added.
Given a preference list L, a slightly quicker method for finding a "good" position p to add to P is to define the set B as the most-preferred tie in L that contains at least one position not already in P. A "good" position is then one in B that also increases |C| q by the smallest amount over all positions in B.

IP Model
We now give an IP model for determining if, given an instance I of HRT, sets P and P ′ can be found that satisfy Theorem 3.
Let I be an instance of HRT with n p positions and n c candidates, and let c k be some particular candidate whose preference list is being processed. Let r i be the rank of position p i according to candidate c k if p i finds c k acceptable, and 0 otherwise. Let P ′′ be a set of positions such that for any p i ∈ P ′′ , (c k , p i ) is not an acceptable pair, and for any stable matching in I, p i is full in I (we discuss how to determine such a set P ′′ in Section 3.4.2). Let A = {i | (c k , p i ) is acceptable}, let B = {i | p i ∈ P ′′ }, and let v ij = 1 if and only if either (a) p i ∈ P ′′ and position p i considers candidate c j to be at least as good as candidate c k , or (b) p i ∈ P ′′ and p i finds c j acceptable.
Define binary variables x i for i ∈ A ∪ B that are set to 1 if and only if position p i is in P ∪ P ′ , and binary variables y j that are set to 1 if and only if candidate c j is in C. Note that if x i = 1 for some i ∈ A, then p i ∈ P, and if x i = 1 for some i ∈ B, then p i ∈ P ′ . We also define the variable z to denote the worst rank of any position in P. An optimal set of preferences to be removed from a preference list can then be found by solving the following integer programming model: Constraints (2) ensures that the variable z will denote the worst rank of any position in P. Constraints (3) ensures that the solution P is nonempty, and constraints (4) ensures that the sets P, P ′ , and C satisfy the capacity requirements of Theorem 3. Lastly, constraints (5) ensure that, if a given position p i is in P, then any competition that c k has for p i is included in C, or, if a given position p i is in P ′ , then any candidate that p i finds acceptable is in C.

Graph-based representation of preprocessing
We now give a graph-based representation of preprocessing, which we rely on in Sections 3.4.1 and 3.4.2 to construct algorithms to detect preprocessing. These new preprocessing algorithms construct a graph iteratively by walking down the preference list, and check the size of a maximum flow of this graph at each iteration. If a maximum flow is sufficiently small (see Theorem 7 below), then any further entries in the preference list can be removed.
The graph will be built based on truncations of the preference list of some particular candidate c whose preference list will be preprocessed. A truncation of a preference list L after t ranks, written L t , contains the first t tie groups in L. An example of such a truncation is given in Example 6. Definition 2. Given an instance I of HRT, a candidate c, a truncation L t of their preference list L, and a set of positions P * such that 1. (c, p) is not acceptable for any p ∈ P * , and 2. any p ∈ P * will be full in any stable matching of I, we construct the graph G[L t ] as follows: First, create one source and one sink vertex. For each p ∈ P * , add a vertex for p to G[L t ], and add an edge from p to the sink with capacity q p . Then, for each candidate c ′ that p finds acceptable, add the edge from c ′ to p with capacity one to G[L t ] (and the vertex c ′ if it is not yet present). Then add to G[L t ] one vertex for each position p in L t , along with an edge from p to the sink with capacity q p . For each such position p, find all candidates c ′ = c such that c ′ p c, and add the edge {c ′ , p} to G[L t ] (and the vertex c ′ if it is not yet present). Lastly, for each vertex representing a candidate c ′ in G[L t ], add an edge from the source to c ′ with capacity q c ′ . Note that we specifically avoid having a vertex for c in this construction.
We note that there is a similarity between P * from Definition 2, and P ′ as used in Theorems 2 and 3, but we highlight the fact that P * and P ′ are not necessarily the same sets. Theorem 7, which we give later, will detail how P ′ may be derived from P * .
An example of the complete construction of a graph G[L t ] is given in Example 6. However to make the graphs simpler to read, we will employ a number of simplification techniques when drawing such graphs. For any truncation L t drawn as in Example 6, all of the edges are oriented from left to right. For each candidate c there is one edge from the source to c with capacity q c , for each position p there is one edge from p to the sink with capacity q p , and there is no other edge incident with either the source or the sink. With that in mind, we will draw such graphs without the source or sink, and we will say the capacity or flow of candidate c (respectively position p) to mean the capacity or flow of the edge from the source to candidate c (respectively the edge from position p to the sink). Unitary capacities of vertices will not be marked, but non-unitary capacities can be written within brackets next to the vertex names. Example 7 demonstrates a simplified drawing of the graph from Example 6. Example 6. We will demonstrate the construction of a network G[L t ] now. Let us take an instance I of HRT with five candidates and four positions such that in any stable matching of I, position p 3 will be assigned to capacity. We only give the required details of the instance for constructing G[L 2 ], where L is the preference list of c 1 . Let some of the preferences of the agents be described by the following: Within I, all candidates have capacity one, p 1 has capacity two, p 2 has capacity three, and p 3 has capacity two. As we know that p 3 will be assigned to capacity in any stable matching of I, we can also let P * = {p 3 }. The preference lists not shown (i.e., those of c 2 , c 3 , c 4 , and p 4 ) and the capacities not given will not be relevant to the construction of G[L t ]. Recall that L 2 is the truncation of L after two ranks. Thus, L 2 is the list p 1 , p 2 , and we construct G[L 2 ] as shown in Figure 1. Example 7. Figure 1 shows an example of G[L t ] drawn. Figure 2 carries the same information as Figure 1, but in a more readable format. For any G[L t ], all edges between a candidate and a position have capacity one, so those capacities are not shown. The edges from the source, or to the sink, have been removed, and the capacities of said edges have instead been either left off (if they are equal to one), or written in parentheses next to the corresponding candidate or position (if they are greater than one). In the rest of this section, we will use this bipartite representation of G[L t ], and the set U (respectively W ) will be used to refer to the set of vertices representing candidates (respectively positions) in this graph.
We begin with the following lemma, which we later use to reason that if there exists in G[L t ] a maximum flow that leaves at least a capacity q c unused through W , then there must also exist in G[L t ] a (possibly different) maximum flow such that the flow through vertices corresponding to positions in P * must be at capacity, meaning that any "unused capacity" is available in vertices that correspond to positions c finds acceptable. This lemma uses concepts from graph theory, specifically maximal flow theory. For a background on this theory, we point the reader to [21]. Lemma 6. Let I be an instance of HRT, let c be some candidate in I with capacity q c , let L t be a truncation of the preference list of c, let P * be as defined in Definition 2, let G[L t ] be the graph constructed as per Definition 2, and let W be all the positions represented in G[L t ]. If there exists a maximum flow F that satisfies |F | ≤ |W | q − q c , then there exists a flow F ′ that satisfies |F ′ | = |F | and the extra criterion that for any p ′ ∈ P * , the flow through p ′ must equal q p ′ , the capacity of p ′ .
Proof. Let F be as given in the lemma. We will write F (p ′ ) to denote the flow in F through p ′ , and similarly for flow F ′ which we will create. Let p ′ ∈ P ′ be a vertex such that the F (p ′ ) < q p ′ , noting that if no such p ′ exists then the theorem holds.
We will create a new flow F ′ such that F ′ (p ′ ) = F (p ′ ) + 1, F ′ (p) = F (p) − 1 for some p ∈ W \ P ′ , and for any other p = ∈ {p, p ′ }, F (p = ) = F ′ (p = ). The result then holds by repeated iteration of this procedure.
We will build an alternating red-blue path that starts at p ′ and ends with some p ∈ W \ P * , at which point swapping along this path gives the new flow F ′ . We will build this path by colouring the edges between the sets of vertices U and W in G[L t ]. In particular, we will use the colours red and blue. Where we say red-degree (respectively blue-degree) of a given vertex v, we mean the number of edges incident to v that are red (respectively blue). Note that unlike common graph colourings, we will allow edges to be assigned multiple colours. We will show that edges in our alternating path are mono-coloured, but edges in the graph that are not in our alternating path may be assigned multiple colours.
First, colour all of the edges that carry non-zero flow in F in blue. Note that each edge between U and W has capacity one, and, by construction, any maximal flow of G[L t ] has integral flow through any edge. Thus, an edge between U and W is blue if it is at capacity, and not blue otherwise. Now take a stable matching in I, and colour the edges corresponding to I in red. Again, as any pair can appear at most once in a matching, each edge either is red if the corresponding pair is in the new stable matching, or is not red otherwise.
We now iteratively build an alternating red-blue path, starting at p ′ . As p ′ ∈ P * , it must have a reddegree of q p ′ . However, it must have a blue-degree less than or equal to q p ′ − 1 as F (p ′ ) < q p ′ . Thus, we begin our alternating path by taking an edge that is red, and not blue.
We follow this red edge to some candidate c ′ . If F (c ′ ) < q c ′ , then we can increase the flow in F by augmenting along the current path, contradicting the fact that F is a maximum flow. Thus it must be that F (c ′ ) = q c ′ , and so c ′ must have a blue-degree of q c ′ . Trivially, its red-degree must be at most q c ′ . So, by the existence of the red-and-not-blue edge (c ′ , p ′ ), there must also be a blue-and-not-red edge incident with c ′ . We then follow this blue-and-not-red edge to some new position p ′′ .
If p ′′ ∈ P * then p ′′ must have a red-degree of q p ′′ , and a blue-degree of at most q p ′′ . By the presence of the blue-and-not-red edge we followed to reach p ′′ , there must be a red-and-not-blue edge incident with p ′′ , and so we can repeat the above procedure. Therefore this process can be repeated until we reach a position p ∈ W \ P * . At this point, we have an even length alternating red-blue path from p ′ to p. By the colouring of the red and blue edges, and as p ′ is not at capacity, we can augment the flow in F by selecting the red edges instead of the blue edges, creating a flow Theorem 7. Let L t be a truncation of the preference list of some candidate c, let P * be a set as defined in Definition 2, let G[L t ] be the graph constructed as per Definition 2, and let W be the positions represented there exist sets C, P, and P ′ that satisfy Theorem 3.
Proof. By Lemma 6, we can assume without loss of generality that for any p ′ ∈ P * , p ′ is at capacity in F . We will build up sets U ′ and W ′ iteratively, use these to construct C, P, and P ′ , and then show that these sets satisfy Theorem 3. We build U ′ and W ′ in turn by adding positions to W ′ , then candidates to U ′ , and then repeating this process until it terminates.
Let S be the set of positions that are not at capacity in F . Note that the flow in through S in F can be at most |S| q − q c by the condition of the theorem. We begin by adding to W ′ all positions in S, then repeat the following: 1. Add the neighbourhood of any position p ∈ W ′ to U ′ .
2. For any neighbour n of a candidate c ∈ U ′ , if there is some flow in F from c to n, add n to W ′ .
First, we note that this process obviously terminates as G[L t ] is a finite graph, and at each step we increase the size of either U ′ or W ′ . Let {s 1 , s 2 } be the source and sink in G[L t ] respectively. We will denote by G ′ the induced subgraph on {s 1 , s 2 } ∪ U ′ ∪ W ′ , and we will denote by F ′ the restriction of F to the subgraph G ′ . Note that if F ′ is not a maximum flow, then there is some augmenting path in G ′ to increase the flow of F ′ . However, this augmenting path would also exist in G[L t ], which contradicts the fact that F is a maximum flow. Thus, it must be that F ′ is a maximum flow in G ′ .
By this construction, if there is a p ∈ W ′ and a candidate c ′ such that c finds p acceptable and c ′ p c, then the edge {c ′ , p} is in G[L t ], and thus in G ′ . Similarly, if there is a p ′ ∈ W and a candidate c ′ such that p ′ is full in any stable matching, (c, p ′ ) is not an acceptable pair, but (c ′ , p ′ ) is an acceptable pair, then the edge {c ′ , p ′ } is in G[L t ] and thus in G ′ . Additionally, by the construction of G[L t ], p ′ is full in any stable matching of I. We make use of these facts at the end of the proof.
Next we show that for any c ′ ∈ U ′ , F ′ (c ′ ) = q c ′ . We show this by demonstrating that if a candidate c ′ ∈ U ′ is not at capacity in F ′ , then there is an augmenting path from c ′ to some undersubscribed p, which contradicts the fact that F ′ is a maximum flow.
Assume that some c ′ ∈ U ′ is undersubscribed. Without loss of generality, take c ′ ∈ U ′ that is not at capacity such that (p, c 1 , p 1 , c 2 , . . . , c k , p k , c ′ ) is a shortest path in G ′ where: As each candidate c ′ ∈ U ′ is at capacity, it is clear that the flow F ′ must satisfy |F ′ | = |U ′ | q . By construction, we also have a set of positions S ⊆ W such that the flow through S is at most |S| q − q c . As any other position in W ′ can at most be at capacity, this gives us |F ′ | ≤ |W ′ | q − q c . We lastly define C = U ′ ∪ {c}, P = {p | p ∈ W ′ and c finds p acceptable }, and P ′ = W ′ \ P. It clearly follows that |C| q = |F ′ | + q c ≤ |W ′ | q = |P| q + |P ′ | q , and by the earlier paragraph these sets satisfy the criteria of Theorem 3, concluding the proof.
Given a preference list L, we can truncate it to create L t for any positive t. If a truncation L t satisfies Theorem 7, then preprocessing according to Theorem 3 is possible with P ⊆ L t . The following theorem states that the reverse is also true: that if preprocessing with P according to Theorem 3 is possible, then for any positive t such that P ⊆ L t , L t will satisfy the criteria of Theorem 7.
Theorem 8. Given a candidate c and their truncated preference list L t , if sets C, P, and P ′ exist that satisfy Theorem 3 such that P ⊆ L t , then the graph G[L t ] has a maximum flow F that satisfies |F | ≤ |W | q − q c , where W is the set of positions represented in G[L t ].
Proof. Construct G[L t ] as per the definition, recalling that U and W denote the candidates and positions represented in G[L t ] respectively, W = P ∪ P ′ , and that U = C \ {c}. The result then holds as any maximum flow F must satisfy |F | ≤ |C| q − q c (as U = C \ {c}, and all flow must pass through U ). So, by

Graph-based algorithms
We now give the algorithms that use the construction and theorems from the previous section to identify preprocessing. For a preference list L of some agent, the algorithms will consider all truncations L t of L in ascending order of length (i.e., t), and construct the graph G[L t ] per Definition 2.
If a maximum flow is too large in a given G[L t ] (i.e. |F | > |W | q − q c ), then Theorem 8 tells us that the preference list cannot be preprocessed at this tie level, and longer truncations of L must be considered. However, Theorem 7 states that if a maximum flow is small enough, preprocessing is possible.
We are also able to take advantage of our particular method of constructing G[L t ]. We build graphs G[L t ] iteratively, and as we will have a maximum flow at each step, we only need to attempt to augment this flow at each step, rather than trying to re-build a complete maximum flow. In addition, we also know that any such augmenting path must include the newest vertex added, else the augmenting path would exist in the previous iteration, a contradiction. Exploiting these features in the implementation of our algorithms significantly improved their performance. Section 3.4.1 gives a basic algorithm that can identify a set P such that preprocessing can be performed (if such a set exists), but this algorithm will always assume that P ′ = ∅. In Section 3.4.2 we then extend this algorithm to also identify a suitable set P ′ . In Section 4 we will see that this second algorithm, while identifying more preprocessing, can also take significantly longer to run.
3.4.1. Graph-based algorithm to find P Algorithm 1 describes the process of building the graphs G[L t ] and finding a maximum flow. If this algorithm returns some t ≥ 1, then any preference list entries appearing after the t-th tie can be removed. The algorithm also may return the sentinel value -1, if no preprocessing was detected. Note that this algorithm only considers the set P; it does not attempt to find a set P ′ . The extension to also find P ′ is described in Section 3.4.2.
Given an instance of HRT with n c candidates and n p positions, we must run Algorithm 1 for each candidate c. Algorithm 1 iterates over each element in the preference list of c exactly once (lines 4-5) for |L| iterations. We then attempt to extend the current flow by finding augmenting paths from each of the newly added vertices that correspond to a position. Each position p is only added to G once, but we need to search for up to q p augmenting paths. Thus, we need to search for augmenting paths a total of p∈L q p times. Each such a search could visit each of the O(n c |L|) edges in G at most once. This gives an asymptotic running time of O(n c |L| · p∈L q p ) for preprocessing one preference list of length L, and such a preference list has length at most n p , so preprocessing a candidate takes O(n c n p p∈L q p ) time.

Algorithm 1 Preprocess one preference list
1: Input: Candidate c with preference list L that is to be preprocessed 2: Output: A rank r such that in a stable matching, c will be allocated a position with rank at most r 3: Let W = ∅, let F = ∅, let G[L t ] be an empty graph 4: for each rank r in L in descending order of preference do 5: for each p in the r-th rank of L do Attempt to find an augmenting path from p to increase the size of F Note that as we are demonstrating only Algorithm 1, P ′ = ∅. We will preprocess the preference list for c 1 . Let q c1 , the capacity of c 1 , be 2, and let q c2 = 1. As this is an instance of HRT, and q c1 > 1, we know that every position must have unitary capacity, and so |W | q = |W | for any set of positions W . The relevant preferences are as follows: Recall that we will be building a graph G[L t ] based on truncations of the preference list of c, and that the source and sink in G[L t ] are not drawn to simplify the diagrams. At each step, we will look for a maximum flow F , and, if |F | ≤ |W | − 2, we stop and perform the actual preprocessing.
We start with an empty graph G[L t ]. First, we add a vertex for p 1 to the right side of G[L t ] (as p 1 is the most preferred choice of c 1 ), and then we add all candidates who can compete with c 1 for position p 1 to the left side of G[L t ]. In our example, this is only c 2 . We also add an edge from p 1 to c 2 to indicate that, if c 2 is paired with p 1 , then (c 1 , p 1 ) will not form a blocking pair. See Figure 3a.
On the next step, we add a vertex for p 2 to the right side of G[L t ]. As there is already a vertex for c 2 in G[L t ], we do not need to add a new vertex, but only a new edge from p 2 to c 2 . In this new graph, a maximum flow (indicated in dashed blue in Figure 3b) still has size 1, and now |W | = 2. However, |F | ≤ 2 − 2 = 0, so we must continue the algorithm.
The algorithm continues with the next step, adding a vertex for p 3 to the right side of G[L t ]. Again, there is already a vertex for c 2 in G[L t ], so we only need to add a new edge from p 3 to c 2 . In this graph, a maximum flow (indicated in dashed blue in Figure 3c) still has size 1, but now |W | = 3. Then |F | ≤ |W | − 1, and we can preprocess. This means we can remove from the preference list of c 1 any positions that c 1 considers worse than p 3 , the last position we added. In this case, this means removing p 4 as an option for c 1 , and removing c 1 as an option for p 4 . Note that we also now know that c 1 will definitely be matched with some position.    Example 9 (Example of Algorithm 1 when ties are present in list being processed). Consider an instance of SMTI with n c = 4 and n p = 3 (i.e., there are 4 candidates and 3 positions). Note that as we are demonstrating only Algorithm 1, P ′ = ∅, and as we have an instance of SMTI, not HRT, we know that every agent has unitary capacity, and thus |W | q = |W |. We will preprocess the preference list for p 1 .
Note that this means we swap the nomenclature for positions and candidates in this example. The relevant preferences are as follows: Again starting with an empty graph G[L t ], we first add vertices for both c 2 and c 1 to G[L t ]. We add vertices for both as they are tied for most preferred candidates by p 1 of the candidates who have not yet been added. However, for both c 1 and c 2 , p 1 is the most preferred position, and so p 1 has no potential competition. This leaves us with a graph of two vertices on the right, but no edges. Therefore |F | ≤ |W | − 1 and so we can preprocess the preference list of p 1 and remove candidates appearing after the tie [c 1 c 2 ]. That is, we remove c 4 and c 3 as options for p 1 .

3.4.2.
Extended graph-based algorithm to find P and P ′ Algorithm 1 does not attempt to find sets P ′ as defined by Theorem 3. To extend Algorithm 1 to support such sets, we need to know some set P ′′ of positions that are guaranteed to be full in any stable matching. Note that P ′′ and P ′ are not the same -for a candidate c, P ′ is a subset of P ′′ containing only positions that c does not find acceptable. A position p can be added to P ′′ if preprocessing the preference list of p results in the removal of some entries from p's preference list. We can also add a position p to P ′′ if, when preprocessing the preference list L of p, L has a length of t and preprocessing indicates that L can be truncated after t ranks. This would result in a truncation of zero preferences from the preference list of p, but this still means that p is always full in any stable matching. Given this set P ′′ , and a candidate c, we can determine the set P ′ . We use this technique to "pre-fill" the graph G[L t ] by replacing line 3 in Algorithm 1 with Algorithm 2.
Using Algorithm 2 in conjunction with Algorithm 1 in this manner results in a complexity of O(n 3 c n 2 p ), the same as for Algorithm 1 by itself, but we show in Section 4 that using Algorithm 2 can under some circumstances significantly increase the runtime for preprocessing, and is not a guaranteed overall performance improvement.
Algorithm 2 Prefill a graph-based on one preference list 1: Input: Candidate c, and a set P ′′ containing positions guaranteed to be filled in any stable matching 2: Output: A graph G, a set W of positions added to G, and a matching M of G 3: Let W = ∅, let F = ∅, let G be an empty graph 4: for each position p ∈ P ′′ do 5: if c does not find p acceptable then 6: Add a vertex p to G 7: Add P to W 8: for each c ′ that p finds acceptable do 9: if c ′ ∈ V (G[L t ]) then for k = 1, . . . , q p do 14: Attempt to find an augmenting path from p to increase the size of F Example 10 (Example of Algorithm 2). Consider an instance of SMTI with n c = n p = 4 (i.e., there are 4 candidates and 4 positions). As we have an instance of SMTI, not HRT, we know that every agent has unitary capacity, and thus |W | q = |W |. We will preprocess the preference list for c 3 . The relevant preferences are as follows: We also know that p 1 ∈ P ′ . That is, in any stable matching, position p 1 will always be matched to some candidate. See the first paragraph of Section 3.4.2 for details on how P ′ may be determined.
Starting with an empty graph G[L t ], we first add a vertex for p 1 to the right of G[L t ], and then one vertex for each acceptable candidate for p 1 (i.e., c 1 and c 2 ) to the left side of G[L t ]. We also add an edge from each of c 1 and c 2 to p 1 . See Figure 4a.
We then start adding vertices by looking at the descending preferences of c 3 . First is p 2 , which we add to the right side of G[L t ], along with edges from p 2 to both c 1 and c 2 , so the graph looks like Figure 4b with a maximum flow in dashed blue. At this point, |F | > |W | − 1, and so we cannot preprocess.
The next position to consider is p 3 , which is handled similarly to p 2 and leaves us with Figure 4c, along with a maximum flow in dashed blue. We can see that as |F | = 2, and |W | = 3, we have |F | ≤ |W | − 1, so we can preprocess. This means removing the position p 4 from the preference list of c 3 .
Note that without using the fact that p 1 is always matched to one of either c 1 or c 2 , we would not be able to determine that c 3 will never be matched with p 4 in a stable matching. This holds even though c 3 does not find p 1 acceptable.

Iteration of preprocessing
All of the preprocessing described earlier in this section explains how to preprocess the preference list of one agent. This must obviously be repeated for each agent, but in addition to this, it is possible that the removal of preferences from the list of agent c i may make preprocessing possible for agent p j . There is also a second consideration if Algorithm 2 is used (i.e., if P ′ is non-empty). In such cases, any changes to P ′ also justify the re-running of preprocessing over all agents.
Our implementation of all preprocessing methods is iterative -each agent has its preference list preprocessed and if any preprocessing is found, the procedure is repeated for all agents. It is possible to only repeat the preprocessing algorithm on the agents whose preferences lists were modified as a result of earlier preprocessing, but initial investigations showed that this had minimal effect on the total runtime of the preprocessing.
For any iteration method, there is at worst a polynomial number of iterations as each iteration must either remove a preference (of which there are at most O(n c n p )), or mark an agent as always being full who had not yet so marked (and there are n c + n p agents in total).
It is plausible to assume that if the preprocessing of the first x% of agents results in no changes (for various values of x), then there will be no preprocessing to complete for any remaining agents either. This assumption was tested for x ∈ {5%, 10%, 25%, 50%}, and we report none of these percentages resulted in a noticeable effect on the running time of the preprocessing. This agreed with the observation that often the earlier iterations of preprocessing both took longer, and removed more preference list entries. In contrast, the final iterations of preprocessing that removed few or no preferences also ran relatively quickly.

Computational results
This section describes our computational experiments on the effectiveness of preprocessing on a number of different classes of stable matching problems. These include MAX-SMTI, MAX-WT-SMTI-GRP, and MAX-HRT, and are described in Section 4.1. Section 4.2 details the particular IP models used to solve these problems, and Section 4.3 describes the experimental setup that we used. Section 4.4 demonstrates that it is rare for any stable matching problem to contain acceptable pairs that do not affect the set of stable matchings, but that our theory (and thus Algorithm 1 combined with Algorithm 2) is unable to detect. Section 4.5 describes the format of our results, including the presentation of resulting data. We show in Section 4.6 that our new preprocessing techniques improve solution times on MAX-SMTI-GRP by up to 44%. In Section 4.7 we look closely at the impact of preference list lengths on the usefulness of preprocessing when solving MAX-SMTI, showing that preprocessing is more effective when agents deem at least 40% of all potential partners as acceptable. Section 4.8 demonstrates that while our new approaches can detect more preprocessing, doing so is not significant when solving MAX-HRT1S. However Section 4.9 shows that when solving MAX-HRT2s, preprocessing can reduce the overall time to find a solution by over 50%. We conclude this section with a discussion in Section 4.10.

Problem instances
We tested three different types of problems: SMTI, SMTI-GRP, and HRT. New instances for this experiment are available from http://dx.doi.org/10.5525/gla.researchdata.904, and were generated using the same code as [8]. All other instances were taken from the literature [8], and are available at https://researchdata.gla.ac.uk/664/.
For SMTI-GRP, we solved MAX-WT-SMTI-GRP on 22 real-world instances of the Coram application, each with 550 agents on one side and 894 agents on the other. We also solved MAX-WT-SMTI-GRP on two sets of 220 instances, generated to resemble the real-world instances. Each of these two correspond to values of a parameter κ ∈ {1, 2}, where the number of agents on one side is κ × 550 and the number of agents on the other side is κ × 894.
For SMTI we first solved MAX-SMTI on a set of 270 instances: 10 each of the 27 possible ways of combining each possible set of parameters taken from the following: The number of candidates (n c ) and positions (n p ) were equal for each instance of SMTI. The parameter "preference list length" is the length of the preference list of each candidate, with each position p ranking exactly those candidates who find p acceptable. Preference list entries were ordered uniformly at random. The tie density is the probability of a preference list entry being tied with its successor.
Our results show that preprocessing has significantly more impact when solving MAX-WT-SMTI-GRP compared to MAX-SMTI. Three factors differ between the MAX-WT-SMTI-GRP instances and the MAX-SMTI instances: the MAX-WT-SMTI-GRP instances had • longer preference lists, • a different objective (maximise weight rather than maximise size), and • some candidates (respectively positions) being more popular amongst all positions (respectively candidates).
Some agents being more popular is not rare in stable matching problems, and this can be modelled using the skew parameter from the generator of Irving and Manlove [14]. A more complete investigation of the skew in our instances of SMTI-GRP is given in [8]. We also can model the weight of a pairing (c, p) by summing together the respective Borda score they assign each other 2 . We generate an additional set of instances to investigate the effect of each of these parameters. These additional instances all have n c = n p = 250, with preference lengths in {100, 150, 200}, and skew values in {5, 10, 15, 20}. For each possible selection of values, we randomly generated 10 different instances. The HRT instances were split into two distinct groups. The first only allowed ties in the preference lists of the hospitals, to allow the comparison with "Hospitals offer" and "Residents apply" [11], while the second set also allows the doctors to have ties in their preference lists.
The first set of instances are denoted HRT-1S (for one-sided ties), and include 3 proprietary instances taken from the Scottish Foundation Allocation Scheme (SFAS), as well as a number of randomly-generated instances intended to simulate this historical real-world application taken from the literature. The randomlygenerated instances are again based on all combinations of the following parameter values: Size is an indicator of the number of doctors and hospitals in the instance, where a value of κ indicates that the instance has κ × 759 doctors and κ × 53 hospitals with a combined κ × 775 available posts. The trio of numbers (759, 53, 775) is taken as an average of the corresponding parameters in the SFAS instances. The second parameter, µ, is used here to replicate the presence of master lists of doctors, a common theme in real-world applications. A value of µ = 0 indicates that no master list is present (and hospital preferences are assigned randomly). Otherwise each doctor is randomly given a score in the range {1, . . . , µ} and hospital preferences are derived from these scores. Doctor preferences are randomly assigned in each instance of HRT.
The second set of instances, which we have generated, are denoted HRT-2S (for two-sided ties) as they allow doctors to also express ties in their preference lists. These instances have a tie density of 0.75, and all combinations of size taken from {1500, 3000, 4000, 8000}, and preference length taken from {5, 10, 25, 50}. This set of randomly-generated instances are intended to test the scalability of our techniques on instances of HRT with two-sided ties and their applicability to the current UK-wide scheme for assigning residents to hospitals, the UK Foundation Programme. The UK Foundation Programme currently has a size of approximately 8000, and doctors are allowed to express up to 20 preferences [1], but further specifics on tie density and actual distribution of preference lengths are not known as they are not published.

Models for solving stable matching problems
The effectiveness of preprocessing is best determined by how much it reduces the time taken to solve the problem, but this requires a suitable benchmark method for solving each problem. As MAX-SMTI, and by extension, MAX-HRT, are NP-hard, IP models are commonly used to find optimal solutions [8,19,20,25]. In [8], the authors introduce and compare a number of different modifications of IP models for stable matching problems. We use the best model (or set of models, if the best model is not clear) according to [8] as the chosen model(s) for these problems. The three important modifications that can be made are as follows: • Stability constraint merging -the merging of stability constraints for a set of agents who are all tied in some preference list.
• Dummy variables -the introduction of dummy variables that denote whether an agent is matched with any other agent at a given rank or better.
• Double stability constraints -the use of stability constraints derived from both sets of agents.
For SMTI, we test with two IP models (models M3 and M4 from [8]). Although both of these models utilise stability constraint merging, they differ in that M4 uses dummy variables and M3 does not. For SMTI-GRP, we again test with two IP models (models M4 and M6 from [8]). Whilst both utilise dummy variables, M4 uses stability constraints derived from the preferences of one set of agents while M6 uses double stability constraints. For HRT, we use two different models. For HRT-1S, we use model N8 from [8], which uses both merged stability constraints and dummy variables. However, N8 uses specific techniques that rely on a lack of ties from the doctors, and as such is unsuitable for HRT-2S. Instead, we use model N4 for HRT-2S. The models were selected as they were reported to be the best choice(s) for each given problem type. For more complete details on these models, we refer the reader to [8].

Experimental setup
The specific code for both the preprocessing and the IP models for finding optimal solutions is available from https://dx.doi.org/10.5281/zenodo.3956390, and was compiled with GCC 7.2.0 using -O2 with Gurobi 7.5.1 as the IP library. All tests were carried out on a computing cluster with two Intel Xeon E5-2687W v3 CPUs per node, each running at 2.60 gigahertz and with 512 gigabytes of memory. At any one time, up to 32 instances were running on a single node (corresponding to the 32 physical cores on each node), and each instance was limited to 15 gigabytes of memory, with the exception of the SMTI instances with 50000 agents, in which case only 8 instances at a time were run with 63 gigabytes of memory each. Time limits were set to one hour combined for both preprocessing and IP solving.

Completeness of preprocessing
Theorem 3 proves that certain pairs in an instance of a stable matching problem can be removed without affecting any solution, and Theorem 8 shows that Algorithm 1 combined with Algorithm 2 is guaranteed to detect if such preprocessing is possible. However, as demonstrated in Example 3, there exist pairs in instances of stable matching problems that never appear in a stable matching, but that Theorem 3 will not be able to detect as never appearing in a stable matching. To test the completeness of our preprocessing, we took each instance I of SMTI with 10000 agents per side and ran Algorithm 1 combined with Algorithm 2 to produce a preprocessed instance I ′ . For each acceptable pair (c, p) in I ′ , we tested whether a stable matching exists that contains (c, p). Results showed that for each of the 90 instances, each acceptable pair (c, p) in I ′ appears in some stable matching of I ′ . This suggests that instances of stable matching problems containing pairs that are not in any stable matching, but are not able to be preprocessed by our theory, are rare. We did find one such example, Example 3, but finding this example involved a computational search through thousands of instances of stable matching problems with only four candidates and four positions.

Presentation of results
The results on the following pages omit some methods of preprocessing. Initial testing on the real-world MAX-WT-SMTI-GRP instances (see below) showed that the two methods from Section 3.1.3 were orders of magnitude slower than Algorithm 1, while finding only a subset of the preferences that Algorithm 1 removed. In addition, in these tests using the IP model from Section 3.2 for preprocessing proved to be too computationally expensive to run any thorough tests on. The implementation required that we solve n c + n p different IPs for each iteration, and whereas most preprocessing techniques took seconds or minutes to complete, the IP-based algorithm would take days to complete for a single instance. Table 1 describes the various preprocessing methods tested. We tested our new methods against not using any preprocessing, P0, and three existing methods, P1, P1', and P1*. P1 is the descending heuristic [8], defined in Section 3.1.1, and P1' is our improved implementation of P1. Both P1 and P1' were only used for SMTI, SMTI-GRP, and HRT2S. For HRT1S, we replaced both of P1 and P1' with P1*, the "Hospitals-offer" and "Residents-apply" methods [14]. We compared these against P2, P3, and P4, three new heuristic methods, P5, our new graph-based algorithm, and P6, the extended version of our new graphbased algorithm. Each results table describes various parameters of our experiments as follows. The five left-most columns in each table correspond to the preprocessing method. The "Name" column is a reference to the type of preprocessing used, as per Table 1. The "Preferences removed" column is an average of the number of preference list entries removed from each instance, and the "Prop. removed" column, short for "proportion removed", indicates what proportion of preference list entries from the whole instance have been removed. The "Runtime" is the average running time of the preprocessing step, and the "num. comp." column, short for "number completed", is the number of instances for which the preprocessing step completed in less than 3600 seconds. The remainder of each table is split into two sets (for SMTI), or one set (for HRT) of three columns, one set of three for each IP model tested for that particular problem type (models M4 and M6 for SMTI-GRP, models M3 and M4 for SMTI, and either model N4 or model N8 for HRT). As a reminder, the rationale for the selection of these models is given in Section 4.2. Of these two sets of three columns in the results tables, the "num. opt." column, short for "number optimal", indicates how many instances were solved to optimality, the "IP Solve" column indicates the average time taken to solve the IP model, and the "Total" column is the average of the combined preprocessing and solving time for the given preprocessing method and IP model. Note that preprocessing is run twice per instance in cases where two IP models were tested. We only show running times from one of these to avoid cluttering the table, which explains why the sum of the preprocessing runtime and the IP solve runtime does not always equal the total runtime. All runtimes are given in seconds. A combined time-limit of 3600 seconds was set for all experiments, and if an optimal solution was not found (including when preprocessing was not completed in under 3600 seconds), the IP solution time was set to 3600. This was done so that the calculations of averages (which include all instances, even those not completed to optimality) did not favour scenarios where the preprocessing took longer (and hence less time was given for the IP solver). Table 2 shows results from the real-world instances, indicating that (just as in [8]) preprocessing can reduce total running time significantly. P5 and P6 both remove significantly more preferences than P1, which would, in turn reduce the model size, at the cost of an increase in the running time of the preprocessing step. The best performance is achieved by preprocessing method P5, combined with IP model M6, reducing total running time by approximately 44% compared to using existing preprocessing techniques, or 80% compared to not using preprocessing. We note that with preprocessing method P1, model M6 significantly outperformed model M4, but when using preprocessing method P6, M4 was solved in only 45 seconds. This was the fastest IP solution time for any choice of model or preprocessing technique by a significant margin.

Results on instances of SMTI-GRP
Comparing preprocessing methods P5 with P6, we see that P6 takes almost four times as long to run (38 seconds compared to 11 seconds), while only removing approximately 4% more preference list entries. However, the removal of this extra 4% of preference list entries almost halves the time taken to solve the IP using M4, showing that the number of preference list entries removed is not necessarily a good indicator for the reduction in model solution times. Table 3 shows that for the augmented instances of a similar size to the real-world data, the new graphbased algorithms again remove significantly more preferences than pre-existing preprocessing methods. However, the reduction in running times is not as impressive, showing only an approximate 19% reduction in total run time compared to existing preprocessing techniques, or 56% compared to not using preprocessing. When we look at augmented instances twice as large as the real-world data (Table 4), we see that no combined method is yet able to solve all 220 instances. Still, our new preprocessing methods are an improvement over existing methods, with P6 and M4 solving 129 instances compared to the 120 solved using P1 and M4, or only 103 solved using M4 without preprocessing.

Results on instances of SMTI
For SMTI, we break down results by the length of preference lists rather than by size, as this highlights when preprocessing is useful. Note that P6 could not even finish preprocessing some of these instances in under 3600 seconds. For such instances, the IP solution time was set to 3600 seconds, as discussed in Section 4.5, even though without preprocessing, all the instances could be solved. The reader should be aware that this means the average figures in the "IP Solve" column may be misleading if P6 is able to preprocess fewer instances than other methods. As a reminder, the "num. comp." column lists the number of instances on which preprocessing successfully completed within the 3600 second time limit, and each of Tables 5, 6, and 7 lists details on running 90 different instances. Table 5 shows that when preferences have length 3, heuristic methods run in under a second on average, while P5 and P6 take 50 seconds and almost 30 minutes on average, respectively. The preprocessing appears to have minimal effect on the IP solution time, so when preferences are very short preprocessing is not useful. This is consistent across both IP models tested.  Table 6 shows experimental results when preferences have a length of 5. Again we see that P5 and P6 both take significantly longer to run than the heuristic preprocessing methods, with P6 only completing the preprocessing step in under an hour on 69 of the 90 instances. We also start to see a difference between the IP models, as M3 can solve all 90 instances in anywhere from 397 to 478 seconds, while M4 can only solve 80 of the 90 and takes upwards of 736 seconds. Looking more closely at the times for M3, we see that without any preprocessing the model takes almost 480 seconds to solve, while with any of the heuristics it only takes around 440 seconds to solve. Even P5 is competitive, as while the preprocessing step takes approximately 50 seconds to run (compared to 1 to 2 seconds for the heuristics), this preprocessing reduces the solution time to below 400 seconds on average.  Table 7 shows experimental results when preferences have a length of 10. We now see that model M4 is outperforming model M3, which is consistent with results in the literature [8]. Again, we also see that P5 takes longer than all the heuristics (approximately 60 seconds compared to 3 to 5 seconds), and that P6 takes so long that it can only preprocess 60 of the 90 instances in under an hour. While there are some differences in the number of instances solved by the different preprocessing methods, we note that the given solution times would indicate that the difference is not that significant. This is based, in part, on both P1 and P1' creating identical models yet P1 is able to solve 4 more instances to optimality than P1'. For example, closer examination shows that the 4 instances solved after preprocessing with P1, but not after preprocessing with P1', were all solved in between 3445 and 3529 seconds, which is within 5% of the timeout of 3600 seconds. Allowing for a 5% variation in individual runtimes would then account for this discrepancy. While Tables 5, 6, and 7 show that preprocessing can be useful for model M3, they do not show a similar result for model M4. Yet our results when testing MAX-WT-SMTI-GRP show that preprocessing can be useful when using model M4 (see, e.g., Table 2). Tables 8, 9, and 10 show the results of using preprocessing to solve MAX-WT-SMTI on skewed 3 instances with fewer agents (n c = n p = 250) but with longer preference lists. Table 8 shows that when preferences are of length 100, model M4 is faster, but we start to also see some differences in running times. The two graph-based preprocessing algorithms both take a few seconds longer to run, but result in models that can be solved faster. We see that by using one of P1, P1', P5, and P6, each of the 40 instances can be preprocessed and solved in approximately 37 seconds, whereas the other methods all take approximately 39-40 seconds. This would indicate that, for instances with 250 candidates and 250 positions, preprocessing is likely to not be useful if candidates each rank fewer than 100 positions, and only if each candidate ranks 100 or more positions is preprocessing useful. Table 9 shows times for instances where candidates rank 150 positions, 60% of the total. Again, P5 and P6 take longer to run, but the benefit is not as evident, with both performing comparably to not using preprocessing. Instead two heuristics, P2 and P3, offer better total performance, with P2 reducing total runtime from approximately 88 seconds without preprocessing down to 68 seconds. Table 10 gives results for instances with preferences of length 200. Here again, the heuristics are the best performers, with P3 solving all instances in an average of 102 seconds compared to 137 seconds without any preprocessing, or 129 seconds using existing preprocessing techniques.

Results on instances of HRT-1S
In these instances, only the hospitals were allowed to have ties in their preference lists, and so P1* was able to be tested. The tables detailing the results of this particular experiment are in Appendix B.1. Here we only report the following summary of the results from the experiments on instances of HRT-1S: • P1*, P2, P3, and P4 all ran in under a second. Of these, P1* removed the most preference list entries.
P5 took 3 seconds on average, while P6 took well over 2000 seconds on average. Despite taking longer than P1*, P5 removed < 0.1% more preference list entries than P1*, and P6 removed < 0.1% more preference list entries than P5.
• P5 and P6 both removed slightly more preference list entries than P1* (at an average of 12208 for P5/P6, and 12205 for P1*), demonstrating that P1* does not remove all possible preference list entries even on randomly generated instances.
• The difference in average IP solution time after any of P0, P1*, P2, P3, P4 or P5, ignoring trivial cases, varies by only a few percent, highlighting the fact that for this particular set of instances, where doctors must give strict preferences with no ties, adding our preprocessing to the internal preprocessing of Gurobi is not useful.

Results on instances of HRT-2S
Recall that instances of HRT-2S allow both hospitals and doctors to express ties in their preference lists, and therefore, P1* is not applicable. Thus, there were no prior techniques for preprocessing HRT-2S instances in the literature, and so we compare all of our new techniques versus not using any preprocessing. Table 11 shows that P3 can cut running times in half, compared to not using preprocessing. Our graphbased algorithms, P5 and P6, both remove slightly more preferences than P3, but take significantly more time to do so. P1 removes very few preferences, and so does not significantly affect the running time of the IP solver. P2 and P4 do remove more preferences than P1, but fewer than P3. We recall that P2 is Skip-5, whereas P3 is Skip-15, P4 is Skip-50, and P1 can be thought of as Skip-∞. Thus, while we see that Skip-15 is the better choice for these instances, we theorise that the specific value 15 may be a parameter that can be tuned for various types of problems. Tables 12 and 13 continue to show similar results, where P3 removes slightly fewer preferences than either P5 or P6, but as both P5 and P6 run significantly slower, P3 still gives the best overall runtime. We note that for instances with 1500, or 4000 doctors, P5 and P6 result in the fastest IP solution times, while with 3000 doctors, P3 results in the fastest IP solution times. Due to the inherent volatility of IP solution times, we do not think any conclusive comparison between P3, and P5 or P6, can be drawn from this.
When we look at instances of HRT-2S with 8000 doctors, we see results that are consistent with results on the smaller instances, with P3 performing the best and managing to solve 118 of the 120 instances in under an hour. Additionally, we see that P5 and P6 are both failing to preprocess many of these larger instances. Even when P5 or P6 do manage to complete preprocessing in under an hour, a close examination of the runtimes shows that P3 still sometimes results in the fastest IP solution time.
A more detailed break-down of experimental results by both size and length of preferences is given in Appendix B.2.

Discussion
The experimental results showed that our new preprocessing techniques can significantly reduce the time required to find optimal stable matchings, with a 44% reduction in running time on real-world instances with the new improvements demonstrated in this paper. However, we also observed that the best preprocessing technique varies depending on the instance or set of instances being solved.
In instances where preference lists were shorter, the new graph-based algorithms (P5 and P6) were often not worth the extra computational cost, as the solution times were not affected by the addition of preprocessing. However even when instances had longer preference lists, preprocessing was useful in reducing the overall computation time to solve instances. One of the Skip-{5,15,50} preprocessing methods (P2, P3,  or P4) was often one of the better, if not the best choice, for preprocessing. However, we also see that the performance of each of these three does vary, with Skip-15 performing worse than all other preprocessing methods on MAX-WT-SMTI-GRP instances with κ = 2, but performing better on MAX-HRT-2S instances. We expect that for certain sets of problems, there is some natural number n such that Skip-n is a good choice for preprocessing, but said value of n may require tuning. In comparison, our new graph-based methods (P5 and P6) do not require any tuning, but are not always useful in solving instances generated at random. In comparison, however, they are shown to be useful on the real-world instances, and on instances devised to mimic real-world instances. We hypothesise that there is some structure present within these instances that P5 and P6 are able to take advantage of, but we have been unable to precisely determine said structure. For our real-world and randomly generated MAX-WT-SMTI-GRP instances, our new graph-based algorithms (P5 and P6) were the best performers. The heuristics also generally improved performance, with some exceptions. The removal of preference list entries can clearly reduce overall running times, however there is not a clear and strong correlation between the number of entries removed, and either the overall running time or the IP solution time.
The results on MAX-SMTI instances where candidates have preference lists of length 3 showed that for these instances, preprocessing was not necessary. Indeed, the time taken to run either method P5 or P6  outstrips the time taken to solve any resulting IP model, with P6, in particular, taking over 40 times longer to complete preprocessing than any IP model took to solve. When preferences are short, then, running preprocessing is not as important. As candidates express more preferences, preprocessing can be useful, as can the introduction of dummy variables in the IP models. There is a narrow band where using preprocessing without dummy variables is important, but if dummy variables are used, candidates must express far longer preferences for preprocessing to become useful. We show that when candidates express 100 or more (of 250 total) positions in their preference lists, using both dummy variables and one of P2 or P3 results in the shortest overall time to find a solution.
When instances of HRT only allowed ties in the hospitals' preferences, preprocessing had minimal impact. However, when ties were present in the preference lists of the doctors, our new preprocessing allowed six additional instances with 8000 doctors and 800 hospitals to be solved. Our preprocessing is shown to consistently improve solution times, with a 53% reduction in average runtime on instances with 1500 doctors, a 55% reduction in average runtime on instances with 3000 doctors, and 24% reduction in average runtime on instances with 4000 doctors.

Conclusion
This paper has introduced a number of new preprocessing heuristics and algorithms for SMTI, as well as the first known preprocessing techniques applicable to HRT with ties on both sides. In doing so, we have given theoretical results extending the existing literature on preprocessing instances of both SMTI and HRT. On instances of SMTI-GRP, we experimentally show that our new preprocessing methods are faster by 44% on real-world instances, and continue to show improvement on randomly generated instances. Further experiments show that, as expected, preprocessing has more impact when candidates express longer preference lists. We also show that for instances of HRT with ties only present in the hospitals' preference lists, our new preprocessing techniques do remove more preference list entries than existing methods, but performance is not noticeably affected. However our preprocessing techniques are the first that are applicable when doctors are also allowed to express ties. In such instances, we are able to improve performance by 24-55% depending on the size of the instance, as well as solving 98% of instances with 8000 doctors that mimic the real-world application involving the UK Foundation Programme, compared to 93% solved without preprocessing.
Future work includes finding further real-world applications of HRT that would allow both hospitals and residents to express indifference, and applying these preprocessing techniques to those problems. Preprocessing may also be extended to matching problems with coalitions, the simplest of which is the extension of HRT that allows couples to take part jointly.
p is in P, and let I ′ be the instance of WFT created from I by marking as unacceptable to c any position p + that satisfies p ≺ c p + for all p ∈ P. Then in any matching M that is stable in I ′ , c is full.
Proof. Assume towards a contradiction that there is a matching M such that M is stable in I ′ but c is not full in M . By the hypothesis of the lemma, M cannot be stable in I, since c is not full in M , so there must be at least one pair that blocks M in I but not in I ′ . By the construction of I ′ , any blocking pair of M in I must be a pair that was marked unacceptable when creating I ′ and therefore any such blocking pair of M must involve c.
The previous paragraph shows that Algorithm 3 can be run on M in I with c = c 0 . By repeatedly calling Algorithm 3 and applying Lemma 11, we can create a matching M ′ from M such that M ′ is stable in I. Consider the last pair of the form (c, p) added to M ′ such that (c, p) remains in M ′ until M ′ is stable, and let M ′′ be the matching as constructed just before (c, p) is added (i.e., as (c, p) is a blocking pair of M ′′ ). We consider the following two cases: p is undersubscribed in M ′′ , and p is full in M ′′ . For either case, we show that (c, p) must have been marked unacceptable in the construction of I ′ .
If p is undersubscribed in M ′′ , then by Lemma 9, p must also be undersubscribed in M . As M is stable in I ′ , and c is also undersubscribed in M , if (c, p) were not marked as unacceptable in the construction of I ′ then (c, p) would block M in I ′ . Therefore, it must be that (c, p) was marked unacceptable to construct I ′ .
Now assume that p is full in M ′′ . Then, as (c, p) blocks M ′′ , there is some c ′ ∈ M ′′ (p) such that p prefers c to c ′ . By Lemma 9, the match profile of p in M ′′ must be at least as good as the match profile of p in M , so p must consider c ′ to be at least as good as some candidate in M (p). That is, there must be a c ′′ ∈ M (p) such that c ′ p c ′′ , and so it follows that c ≺ p c ′′ . Again, we see that for (c, p) to not block M in I ′ , it must be that (c, p) was marked unacceptable to create I ′ .
We now know that (c, p) must have been marked unacceptable in the construction of I ′ , and (c, p) ∈ M ′ . However, this means that p ′ ≺ c p for all p ′ ∈ P. Thus, as M ′ is stable in I, this means that in a stable matching of I, c is assigned a position not in P, which is a contradiction. The following tables (Table B.20 through to Table B.35) contain results of the same experiments as those that produced Tables 11, 12, 13, and 14. These tables, however, are split up based not only on size, but also on lengths of preference lists of the doctors.