How good are Popular Matchings?

04/28/2018 ∙ by Krishnapriya A M, et al. ∙ 0

In this paper, we consider the Hospital Residents problem (HR) and the Hospital Residents problem with Lower Quotas (HRLQ). In this model with two sided preferences, stability is a well accepted notion of optimality. However, in the presence of lower quotas, a stable and feasible matching need not exist. For the HRLQ problem, our goal therefore is to output a good feasible matching assuming that a feasible matching exists. Computing matchings with minimum number of blocking pairs (MinBP) and minimum number of blocking residents (MinBR) are known to be NP-Complete. The only approximation algorithms for these problems work under severe restrictions on the preference lists. We present an algorithm which circumvents this restriction and computes a popular matching in the HRLQ instance. We show that on data-sets generated using various generators, our algorithm performs very well in terms of blocking pairs and blocking residents. Yokoi (ISAAC 2017) recently studied envy-free matchings for the HRLQ problem. We propose a simple modification to Yokoi's algorithm to output a maximal envy-free matching. We observe that popular matchings outperform envy-free matchings on several parameters of practical importance, like size, number of blocking pairs, number of blocking residents. In the absence of lower quotas, that is, in the Hospital Residents (HR) problem, stable matchings are guaranteed to exist. Even in this case, we show that popularity is a practical alternative to stability. For instance, on synthetic data-sets generated using a particular model, as well as on real world data-sets, a popular matching is on an average 8-10 matches more number of residents to their top-choice, and more residents prefer the popular matching as compared to a stable matching. Our comprehensive study reveals the practical appeal of popular matchings for the HR and HRLQ problems.



There are no comments yet.


page 1

page 2

page 3

page 4

This week in AI

Get the week's most popular data science and artificial intelligence research sent straight to your inbox every Saturday.

1 Introduction

In this paper, we study two problems – the Hospital Residents (HR) problem and the Hospital Residents problem with Lower Quotas (HRLQ). The input to the HR problem is a bipartite graph where denotes a set of residents, denotes a set of hospitals, and an edge denotes that and are acceptable to each other. Each vertex has a preference list which is a strict ordering on its neighbors. Further, each hospital has a positive upper-quota . In the HRLQ problem, additionally, a hospital has a non-negative lower-quota . A matching is a subset of such that every resident is assigned at most one hospital and every hospital is assigned at most upper-quota many residents. Let denote the hospital to which resident is matched in . Analogously, let denote the set of residents that are matched to in . A matching in an HRLQ instance is feasible if for every hospital , . The goal is to compute a feasible matching that is optimal with respect to the preferences of the residents and the hospitals. When both sides of the bipartition express preferences, stability is a well-accepted notion of optimality. A stable matching is defined by the absence of a blocking pair.

Definition 1

A pair blocks if either is unmatched in or prefers over and either or prefers over some . A matching is stable if there does not exist any blocking pair w.r.t. , else is unstable.

From the seminal result of Gale and Shapley [12], it is known that every instance of the HR problem admits a stable matching and such a matching can be computed in linear time in the size of the instance. In contrast, there exist simple instances of the HRLQ problem which do not admit any matching that is both feasible and stable.

Figure 1: A hospital residents instance with and . The quotas of the hospitals are . The preferences can be read from the tables as follows: prefers over and so on. The three matchings , and are shown below. and are feasible but unstable since blocks and blocks . .

Figure 1 shows an HRLQ instance where has a lower-quota of . The instance admits a unique stable matching which is not feasible. The instance admits two maximum cardinality matchings and , both of which are feasible but unstable. This raises the question what is an optimal feasible matching in the HRLQ setting?

Our goal in this paper is to propose popularity as a viable option in the HRLQ setting, and compare and contrast it by an extensive experimental evaluation with other approaches proposed for this problem. Before giving a formal definition of popularity, we describe some approaches from the literature to the HRLQ problem.

Hamada et al. [14] proposed the optimality notions (i) minimum number of blocking pairs (Min-BP) or (ii) minimum number of residents that participate in any blocking pair (Min-BR). Unfortunately, computing a matching which is optimal according to any of the two notions is NP-Hard as proved by Hamada et al. [14]. On the positive side, they give approximation algorithms for a special case of HRLQ, complemented by matching inapproximability results. Their approximation algorithms require that all the hospitals with non-zero lower-quota have complete preference lists (CL-restriction).

There are two recent works [18, 20] which circumvent the CL-restriction and work with the natural assumption that the HRLQ instance admits some feasible matching. Nasre and Nimbhorkar [18] consider the notion of popularity and show how to compute a feasible matching which is a maximum cardinality popular matching in the set of feasible matchings. Yokoi [20] considers the notion of envy-freeness in the HRLQ setting. We define both popularity and envy-freeness below.

Popular matchings: Popular matchings are defined based on comparison of two matchings with respect to votes of the participants. To define popular matchings, first we describe how residents and hospitals vote between two matchings and . We use the definition from [18]. For a resident unmatched in , we set and assume that prefers to be matched to any hospital in his preference list (set of acceptable hospitals) over . Similarly, for a hospital with capacity , we set the positions in to , so that is always equal to . For a vertex , if prefers over , if prefers over and if . Thus, for a resident , .

Voting for a hospital: A hospital is assigned -many votes to compare two matchings and ; this can be viewed as one vote per position of the hospital. A hospital is indifferent between and as far as its positions are concerned. For the remaining positions of hospital , the hospital defines a function . This function allows to decide any pairing of residents in to residents in . Under this pairing, for a resident , is the resident in corresponding to . Then . As an example, consider and and . To decide its votes, compares between and and one possible is to pair with and with . Another function is to pair with and with . The choice of the pairing of residents using is determined by the hospital . With the voting scheme as above, popularity can be defined as follows:

Definition 2

A matching is more popular than if . A matching is popular if there is no matching more popular than .

It is interesting to note that the algorithms for computing popular matchings do not need the function as an input. The matching produced by the algorithms presented in this paper is popular for any function that is chosen.

Definition 3

Given a feasible matching in an HRLQ instance, a resident has justified envy towards with if prefers over and is either unmatched or prefers over . A matching is envy-free if there is no resident that has a justified envy towards another resident.

Thus envy-freeness is a relaxation of stability. A matching that is popular amongst feasible matchings always exists [18], but there exist simple instances of the HRLQ problem that admit a feasible matching but do not admit a feasible envy-free matching. Yokoi [20] gave a characterization of HRLQ instances that admit an envy-free matching and an efficient algorithm to compute some envy-free matching.

An envy-free matching need not even be maximal. In the example in Figure 1 the matching is envy-free. Note that is not maximal, and not even a maximal envy-free matching. The matching is a maximal envy-free matching, since addition of any edge to violates the envy-free property. The matchings and shown in Figure 1 are not envy-free, since has justified envy towards in whereas has a justified envy towards in . The algorithm in  [20] outputs the matching which need not even be maximal; Algorithm 2 in Section 2.2 outputs which is guaranteed to be maximal envy-free. Finally, the Algorithm 1 in Section 2.1 outputs (see Figure 1) which is both maximum cardinality as well as popular.

Popularity is an interesting alternative to stability even in the absence of lower-quotas, that is, in the HR problem. The HR problem is motivated by large scale real-world applications like the National Residency Matching Program (NRMP) in US [3] and the Scottish Foundation Allocation Scheme (SFAS) in Europe [4]. In applications like NRMP and SFAS it is desirable from the social perspective to match as many residents as possible so as to reduce the number of unemployed residents and to provide better staffing to hospitals. Birò et al. [7] report that for the SFAS data-set (2006–2007) the administrators were interested in knowing if relaxing stability would lead to gains in the size of the matching output. It is known that the size of a stable matching could be half that of the maximum cardinality matching , whereas the size of a maximum cardinality popular matching is at least (see e.g. [16]). Thus, theoretically, popular matchings give an attractive alternative to stable matchings.

Popular matchings have gained lot of attention and there have been several interesting results in the recent past  [6, 8, 10, 9, 16, 18, 19]. The algorithms used and developed in this paper, are inspired by a series of papers [9, 11, 16, 18, 19]. One of the goals in this paper is to complement these theoretical results with an extensive experimental evaluation of the quality of popular matchings. We now summarize our contributions below:

1.1 Our contribution

Results for HRLQ: Algorithm for popular matchings: We propose a variant of the algorithm in [18]. Whenever the input HRLQ instance admits a feasible matching, our algorithm outputs a (feasible) popular matching amongst all feasible matchings. We report the following experimental findings:

  • Min-BP and Min-BR objectives: In all the data-sets, the matching output by our algorithm is at most times the optimal for the Min-BP problem and very close to optimal for the Min-BR problem. In the HRLQ setting, no previous approximation algorithm is known for incomplete preference lists. The only known algorithms which output matchings with theoretical guarantees for the Min-BP and Min-BR problems work under the CL-restricted model [14]. We remark that the algorithm of [18] can not provide any bounded approximation ratio for Min-BP and Min-BR problems as it may output a feasible matching with non-zero blocking pairs and non-zero blocking residents even when the instance admits a stable feasible matching.

  • Comparison with envy-free matchings: Based on the algorithm by Yokoi [20], we give an algorithm to compute a maximal envy-free matching, if it exists, and compare its quality with a popular matching. Besides the fact that popular matchings exist whenever feasible matchings exist, which is not the case with envy-free matchings, our experiments illustrate that, compared to an envy-free matching, a popular matching is about 32%–43% larger, matches about 15%–38% more residents to their top choice and has an order of magnitude fewer blocking pairs and blocking residents.

Empirical Evaluation of known algorithms for HR : For the HR problem, we implement and extensively evaluate known algorithms for maximum cardinality popular matching and popular amongst maximum cardinality matching on synthetic data-sets as well as limited number of real-world data-sets.

  • Our experiments show that a maximum cardinality popular matching, as well as popular amongst maximum cardinality matchings are 8–10 larger in size than a stable matching. We also observe that a maximum cardinality popular matching almost always fares better than a stable matching with respect to the number of residents matched to their rank-1 hospitals, and the number of residents favoring a maximum cardinality popular matching over a stable matching.

We note that these properties cannot be proven theoretically as there are instances where they do not hold. Despite these counter-examples (see Appendix 5) our empirical results show that the desirable properties hold on synthetic as well as real-world instances. Hence we believe that popular matchings are a very good practical alternative.

Organization of the paper: In Section 2.1, we present our algorithm to compute a matching that is popular amongst feasible matchings for the HRLQ problem. Our algorithm for computing a maximal envy-free matching is described in Section 2.2. In Section 3 we give details of our experimental setup and the data-generation models developed by us. Section 4 gives our empirical results for the HRLQ and HR problems. We refer the reader to [9, 19] for known algorithms for computing popular matchings in the HR problem.

2 Algorithms for Hrlq problem

In Section 2.1, we present our algorithm to compute a popular matching in the HRLQ problem. As mentioned earlier, our algorithm is a variant of the algorithms in  [18]. The algorithm to find a maximal envy-free matching is given in Section 2.2, and its output is a superset of the envy-free matching computed by Yokoi’s algorithm [20].

2.1 Algorithm for Popular matching in Hrlq

In this section, we present an algorithm (Algorithm 1) that outputs a feasible matching in a given HRLQ instance , such that is popular amongst all the feasible matchings in . We assume that admits a feasible matching, which can be checked in polynomial time [14].

Algorithm 1 is a modification of the standard hospital-proposing Gale and Shapley algorithm [12] and can be viewed as a two-phase algorithm. The first phase simply computes a stable matching in the input instance ignoring lower quotas. If satisfies the lower quotas of all the hospitals, it just outputs . Otherwise hospitals that are deficient in propose with increased priority. A hospital is deficient w.r.t. a matching if . We implement the increased priority by assigning a level to each hospital, so that higher level corresponds to higher priority. A resident always prefers a higher level hospital in its preference list to a lower level hospital, irrespective of their relative positions in its preference list. We show that at most levels suffice to output a feasible matching in the instance, if one exists. We give a detailed description below.

1:Input :
2:set ; ;
3:for each  do set level() = 0; add to ;
4:for each  do set level() = -1;
5:while  is not empty do
6:      let head();
7:      let = residents to whom has not yet proposed with level();
8:      if   then
9:            let be the most preferred resident in
10:            if  is matched in (to say then
11:                 if  pref() == 0 then
12:                       add to ; goto Step 5;
13:                 else
14:                       ;
15:                       add to if is not present in ;                              
16:            ; level() = level();
17:            if  level() == 0 and  then
18:                 add to ;
19:            else if  and  then
20:                 add to ;             
21:      else if  and level() ¡  then
22:            level() = level()+1; add to ;
23:            // starts proposing from the beginning of the preference list.       
Algorithm 1 Popular matching in HRLQ

Let be the given HRLQ instance. Let denote the set of hospitals which have non-zero lower quota – we call a lower-quota hospital; we call a non-lower quota hospital.

Algorithm 1 begins by initializing the matching and a queue of hospitals to be empty (Step 2). As described above, level of a hospital denotes its current priority, and initially all the hospitals have level . All hospitals are added to (Step 3). We also assign a level to each resident , which stores the level of the hospital at the time when gets matched to . Initially, all residents are assigned level (Step 4). The main while loop of the algorithm (Step 5) executes as long as is non-empty. Steps 616 are similar to the execution of the hospital-proposing Gale-Shapley algorithm [13]. When a matched resident gets a proposal from a hospital , compares its current match with using pref. We define pref if level level, which means proposes to with a higher priority than did, or level level and has a higher position than in the preference list of . We define pref otherwise. Thus matched resident accepts the proposal of and rejects if and only if pref . In case the edge is added to (Step 16), the algorithm also sets the level of equal to the level().

When a hospital finishes proposing all the residents on its preference list with level and still , level is incremented by and is added back to . This is done in Step 21. Now restarts proposing all the residents in its preference list with the new value of level.

Running time and correctness: To see that the algorithm terminates we observe that every non-lower quota hospital proposes to residents in its preference list at most once. Every lower-quota hospital proposes to residents on its preference list at most times. Thus the running time of our algorithm is . To see the correctness note that when admits a feasible stable matching our algorithm degenerates to the standard Gale-Shapley hospital proposing algorithm. As proved in [19], a stable matching is popular amongst the set of feasible matchings. In case admits a feasible matching but no feasible stable matching, techniques as in [18] can be employed to show that the output is popular amongst the set of feasible matchings.

Theorem 2.1

In an HRLQ instance , Algorithm 1 outputs a matching that is feasible and popular amongst the set of feasible matchings. If admits a feasible and stable matching, then Algorithm 1 outputs a stable matching.

2.2 Algorithm for Maximal Envy-free Matching

Yokoi [20] has given an algorithm to compute an envy-free matching in an HRLQ instance . Yokoi’s algorithm works in the following steps:

  1. Set the upper quota of each hospital to its lower quota.

  2. Set the lower quota of each hospital to , call this modified instance .

  3. Find a stable matching in the modified instance.

  4. Return , if every hospital gets matched to as many residents as its upper quota in , otherwise declare that there is no envy-free matching in .

It can be seen that Yokoi’s algorithm, as stated above, does not return a maximal envy-free matching. In particular, any hospital with lower-quota does not get matched to any resident in Yokoi’s algorithm. Hence we propose a simple extension of Yokoi’s algorithm to compute a maximal envy-free matching, which contains the matching output by Yokoi’s algorithm. We call a matching in maximal envy-free if, for any edge , is not envy-free. The following definition with respect to Yokoi’s output matching is useful for our algorithm. Our algorithm is described as Algorithm 2.

Definition 4

Let be a hospital that is under-subscribed in with respect to , that is . A threshold resident for , if one exists, is the most preferred resident in the preference list of such that is matched in , to say , and prefers over . If no such resident exists, we assume a unique dummy resident at the end of ’s preference list to be the threshold resident for .

1:Input :
2:Compute a matching by Yokoi’s algorithm.
3:if Yokoi’s algorithm declares “no envy-free matching” then
4:      Return .
5:Let be the set of residents unmatched in .
6:Let be the set of hospitals such that in .
7:Let be an induced subgraph of , where . Set in as in .
8:Each has the same relative ordering on its neighbors in as in .
9: = stable matching in .
10:Return .
Algorithm 2 Maximal envy-free matching in HRLQ

Below we prove that the output of Algorithm 2 is a maximal envy-free matching.

Theorem 2.2

If admits an envy-free matching, then Algorithm 2 outputs which is maximal envy-free in .


Since admits an envy-free matching, output by Yokoi’s algorithm is non-empty. We prove that is an envy-free feasible matching, and for each edge , is not an envy-free matching.

is envy-free: Assume, for the sake of contradiction, that a resident has a justified envy towards a resident with respect to . Thus prefers over , and prefers over . The edge and hence either or . Suppose . Recall that is stable in the instance used in Yokoi’s algorithm. In this case, the edge blocks in a contradiction to the stability of in .

Thus, if possible, let , and hence . If is unmatched in , then and blocks in , contradicting the stability of in . If is matched in then and hence . In this case, the threshold resident of is either same as or is a resident whom prefers over . Since prefers over , prefers over . Therefore can not be in by construction, and hence . This proves that is envy-free.

is maximal envy-free: We now prove that, for any , is not envy-free. Let . Clearly, must be under-subscribed in i.e. , and must be unmatched in , otherwise is not a valid matching in . Let be the threshold resident of with respect to . Since is unmatched in and hence in , . (i) If prefers over , then blocks in , which contradicts the stability of in . (ii) If prefers over , then adding the edge to makes have a justified envy towards . Thus, is not envy-free.

3 Experimental Setup

The experiments were performed on a machine with a single Intel Core i7-4770 CPU running at 3.40GHz, with 32GB of DDR3 RAM at 1600MHz. The OS was Linux (Kubuntu 16.04.2, 64 bit) running kernel 4.4.0-59. The code [5] is developed in C++ and was compiled using the clang-3.8 compiler with -O3 optimization level. To evaluate the performance of our algorithms, we developed data generators which model preferences of the participants in real-world instances. We use a limited number of publicly available data-sets as well as real-world data-sets from elective allocation at IIT-Madras. All the data-sets generated and used by us are available at [1].

3.1 Data generation models and available data-sets

There are a variety of parameters and all of them could be varied to generate synthetic data-sets. We focus on four prominent parameters – the number of residents , the number of hospitals , the length of the preference list of each resident , capacity of every hospital (by default ). In the synthetic data-sets, all hospitals have uniform capacity and all residents have the same length of preference list. We use the following three models of data generation, and data-sets publicly available from [2].

  1. Master

    : Here, we model the real-world scenario that there are some hospitals which are in high demand among residents and hence have a larger chance of appearing in the preference list of a resident. Hospitals on the other hand, rely on some global criteria to rank residents. We set up a geometric probability distribution with

    over the hospitals which denotes the probability with which a hospital is chosen for being included in the preference list of a resident. Each resident samples hospitals according to the distribution and orders them arbitrarily. We also assume that there exists a master list over the set of residents. For all the neighbours of a hospital, the hospital ranks them according to the master list of residents.

  2. Shuffle: This model is similar to the first model except that we do not assume a master list on the residents. The residents draw their preference lists as above. Every hospital orders its neighbours uniformly at random. This models the scenario that hospitals may have custom defined ranking criteria. Our Shuffle model is closely inspired by the one described by Mahdian and Immorlica [15].

  3. Publicly available HR with couples data-set: Other than generating data-sets using the three models described above, we used a freely available data-set [2] by Manlove et al. [17] for the HR problem with couples (HRC problem). The instances were only modified with respect to the preference list of residents that participate in a couple, all other aspects of the instance remain the same. Residents participating in a couple can have different copies of a same hospitals on their preference list which are not necessarily contiguous. The preference list is created by only keeping the first unique copy of a hospital in the preference list of a resident.

  4. Elective allocation data from IIT-M: We use a limited number of real-world data-sets available from the IIT Madras elective allocation. The data-sets are obtained from the SEAT (Student Elective Allocation Tool) which allocates humanities electives and outside department electives for under-graduate students across the institute every semester. The input consists of a set of students and a set of courses with capacities (upper-quotas). Every student submits a preference ordering over a subset of courses and every course ranks students based on custom ranking criteria. This is exactly the HR problem.

HRLQ instances: The above three data-generation models (Master, Shuffle, and Random) are common for generating preferences in HRLQ and HR data-sets. For HRLQ data-sets we additionally need lower quotas. In all our data-sets, around 90% of the hospitals had lower quota at least 1. This is to ensure that the instances are HRLQ instances rather than nearly HR instances. Also, the sum of the lower quota of all the hospitals was kept around 50% of the total number of positions available. This ensures that at least half of the residents must be matched to a lower quota hospital. Lastly, we consider only those HRLQ instances which admit a feasible matching but no stable feasible matching. This is done by simply discarding instances that admit a feasible stable matching. We discard such instances because if an instance with feasible stable matching, the stable matching is optimal with respect to popularity, envy-freeness and min-BP and min-BR objectives.

Methodology: For reporting our results, we fix a model of generation and the parameters . For the chosen model and the parameters, we generate 10 data-sets and report arithmetic average for all output parameters on these data-sets.

4 Empirical Evaluation

Here, we present our empirical observations on HRLQ and HR instances. In each case, we define set of parameters on the basis of which we evaluate the quality of our matchings.

4.1 Hrlq instances

In this section we show the performance of Algorithm 1 and Algorithm 2 on data-sets generated using models described earlier. Let be an instance of the HRLQ problem, and be the stable matching in the instance ignoring lower-quotas. For all our instances is infeasible. Let denote a popular matching output Algorithm 1 in . Let denote a maximal envy-free matching output by Algorithm 2. Both and are feasible for and hence unstable.

Parameters of interest: We now define the parameters of the matching that are of interest in the HRLQ problem. For we compute the following.

  • size of the matching in .

  • number of blocking pairs w.r.t. in . Since is not stable in , this parameter is expected to be positive; however we would like this parameter to be small.

  • number of residents that participate in at least one blocking pair w.r.t. .

  • number of residents matched to their rank-1 hospitals in .

We additionally compute the deficiency of the stable matching . Hamada et al. [14] showed that is a lower bound on the number of blocking pairs and the number of blocking residents in an HRLQ instance. To analyze the goodness of and w.r.t. the Min-BP and Min-BR objectives, we compare the number of blocking pairs and blocking residents with the lower bound of .

  • This parameter denotes the deficiency of the stable (but not feasible) matching in . For every hospital , let . The deficiency of the instance is the sum of the deficiencies of all hospitals.

We now describe our observations for the data-sets generated using various models. For a particular model, we vary the parameters to generate HRLQ data-sets using the different models. In all our tables a column with the legend implies that larger values are better. Analogously, a column with the legend implies smaller values are better.

4.1.1 Popular Matchings versus Maximal Envy-free Matchings

Here we report the quality of popular matchings and envy-free matchings on the parameters of interest listed above on different models.

100 30.80 885.40 559.00 78.50 2747.00 34.80 822.00 554.10 174.00
20 23.60 897.90 510.66 67.70 3067.33 27.50 803.66 570.40 195.33
10 27.50 912.80 535.50 85.10 2945.00 31.10 770.87 600.40 226.87
Table 1: Data generated using the Master model. All values are absolute. .

Table 1 shows the results for popular matchings () and maximal envy-free matchings () on data-sets generated using the Master model.

Table 2 shows the results for popular matchings () and maximal envy-free matchings () on data-sets generated using the Shuffle model.

100 17.00 892.70 27.20 19.40 350.30
20 20.60 915.30 547.00 34.40 2838.20 23.60 808.00 343.90 185.80
10 35.40 930.00 490.33 57.80 3388.00 35.40 853.00 309.30 147.00
Table 2: Data generated using the Shuffle model. All values are absolute..

We observe the following from the above two tables.

  • Guaranteed existence: As noted earlier, envy-free matchings are not guaranteed to exist in contrast to popular matchings which always exist in HRLQ instances. For instance, in the Shuffle model, for (Table 2, Row 1) none of the instances admit an envy-free matching. Thus, for the columns we take an average over the instances that admit an envy-free matching.

  • Size: It is evident from the tables that in terms of size popular matchings are about 32%–43% larger as compared to envy-free matchings (when they exist). See Column in Table 1 and Table 2.

  • BPC and BR: In terms of the blocking pairs and blocking residents, popular matchings beat envy-free matchings by over an order of magnitude. We remark that to ensure envy-freeness, several hospitals may to be left under-subscribed. This explains the unusually large blocking pairs and blocking residents in envy-free matchings. Furthermore, note that is a lower-bound on both the number of blocking pairs and blocking residents. On all instances, for popular matchings the number of blocking pairs (BPC) is at most times the optimal whereas the number of blocking residents (BR) is close to the optimal value.

  • Number of Envy-pairs: Although we do not report it explicitly, the number of envy pairs in an envy-free matching is trivially zero and for any matching it is upper bounded by the number of blocking pairs. Since the number of blocking pairs is significantly small for popular matchings, we conclude that the number of envy-pairs is also small.

  • Number of residents matched to rank-1 hospitals: For any matching, a desirable criteria is to match as many participants to their top-choice. Again on this count, we see that popular matchings match about 15%–38% more residents to their top choice hospital (See Column in the above tables).

4.2 Results on HR instances

To analyze the quality of popular matchings on various data-sets, we generate an HR instance , compute a resident optimal stable matching , a maximum cardinality popular matching and a popular matching among maximum cardinality matchings . The matchings and are generated by creating reduced instances and respectively, and executing the resident proposing Gale-Shapley algorithm in the respective instance. Theoretically, we need to construct for computing , practically we observe that almost always a constant number suffices say constructing suffices. We now describe our output parameters.

Parameters of interest: For any matching , let denote the number of residents matched to rank-1 hospitals in . For two matchings and , let denote the number of residents that prefer over . For each instance we compute the following:

  • size of the stable matching in .

  • For to be one of or define:

    • . This denotes the percentage increase in size of when compared to . When comparing with either or , is guaranteed to be non-negative. The larger this value, the better the matching in terms of size as compared to .

    • . This denotes the percentage increase in number of rank-1 residents of when compared to . As discussed in the Introduction, there is no guarantee that this value is non-negative. However, we prefer that the value is as large as possible.

    • . This denotes the percentage increase in number of resident votes of when compared to . Similar to , there is no apriori guarantee that more residents prefer over . A positive value for this parameter indicates that is more resident popular as compared to . That is, in an election where only residents vote, a majority of the residents would like to move from to .

    • . The minimum value for can be (for a stable matching) and the maximum value can be 100, due to the choice of the denominator (). Since matchings and are not stable, this parameter is expected to be positive and we consider it as the price we pay to get positive values for , and .

We now present our results on data-sets generated using different models. In each case we start with a stable marriage instance (with ) and gradually increase the capacity. As before, a column with the legend implies that larger values are better for that column. Analogously, a column with the legend implies smaller values are better.

vs vs
757.90 11.81 4.66 -3.49 5.25 12.79 5.34 -4.02 6.41
823.50 12.93 8.57 -1.64 7.41 13.99 9.96 -2.80 8.58
870.70 11.65 12.22 0.24 7.32 12.25 14.47 -0.36 7.47
890.00 10.68 16.32 0.76 2.37 10.80 16.57 0.73 2.64
Table 3: Data generated using the Master model. All values except are percentages.

Master : Table 3 shows our results on data-sets generated using the Master model. Here, we see that for all data-sets we get at least 10.5% increase in the size when comparing vs (column 3) and vs (column 7). The negative value of (columns 5 and 9) indicates that we reduce the number of residents matched to their rank-1 hospitals by at most % in our experiments and we also marginally gain for smaller values of . The parameter is observed to be positive which shows that a majority of residents prefer over (column 6) and also prefer over (column 10). Finally, the value of (columns 4 and 8) goes on increasing as we reduce the value of .

Shuffle : The results obtained on data-sets generated using the Shuffle model are presented in Table 4. The size gains are at least 6% when comparing with (column 3) and (column 7). Looking at the values of from column 5 and column 9 we see that the number of residents matched to their rank-1 hospitals are almost always more, with up to 18% getting their rank-1 choices. We also observe that is always positive, which implies that majority of the residents prefer and over .

vs vs
776.80 9.39 2.33 0.52 4.27 10.20 2.80 -0.14 5.39
856.00 8.56 3.55 8.72 7.80 9.23 4.13 9.79 9.38
900.80 7.10 5.50 13.87 9.86 7.52 6.01 15.55 11.37
935.40 6.03 16.57 17.35 5.77 6.15 16.76 18.02 6.32
Table 4: Data generated using the Shuffle model. All values except are percentages.

Processed HR couples data-set: Table 5 shows our results on publicly available HR with couples data-set [2]. As seen from the columns with different values, popular matchings perform favourably on all desired parameters on these data-sets. This is similar to our observations on data generated using the Shuffle model. We also investigated the relation between data generated using Shuffle model and the data used in this experiment and found that the data-sets are similar in their characteristics. This confirms that Shuffle is a reasonable model. Our results on these data-sets confirm that popular matchings perform favourably on variants of the Shuffle model.

vs vs
84.67 10.10 6.26 2.79 4.62 11.81 8.55 1.20 7.16
87.19 9.61 8.25 4.53 4.99 11.01 10.77 3.12 6.47
91.35 7.92 13.57 9.30 4.28 8.41 14.93 8.22 3.86
93.53 6.61 19.94 5.34 -1.86 6.73 20.43 4.99 -2.00
Table 5: Processed data-sets from [2]. All values except are percentages.

Real world data-sets from IIT-M: Table 6 shows our results on data-sets obtained from the IIT-M elective allocation (the three rows in the table correspond to the Aug–Nov 2016, Jan–May 2017 and Aug–Nov 2017 humanities elective allocation data respectively).

, avg. pref. length vs vs
18 5313 11.00 481 0.41 1.32 0 -0.20 0.41 1.32 0 -0.20
16 4534 6.21 675 8.00 31.98 7.39 -5.48 8.00 31.98 7.39 -5.48
14 2689 4.10 487 18.27 16.42 14.97 7.17 23.81 29.91 24.06 5.49
Table 6: Real data-sets from IIT-M elective allocation. All values except are percentages.

For each data-set we list the number of students (), the number of courses (), the sum of total preferences () and the average preference list over the set of students (). On an average, each course has a capacity of 50. For each course a custom ranking criteria is used to rank students who have expressed preference in the course. As seen in Table 6, for the Jan–May 2017 (row 2) and Aug–Nov 2017 (row 3) data-sets, popular matchings perform very favourably as compared to stable matching.


  • [1] Data sets.
  • [2] HR with couples data-set.
  • [3] National Residency Matching Program.
  • [4] Scottish Foundation Association Scheme.
  • [5] Source code repository.
  • [6] Abraham, D.J., Irving, R.W., Kavitha, T., Mehlhorn, K.: Popular Matchings. SIAM Journal on Computing 37(4), 1030–1045 (2007)
  • [7] Biró, P., David F. Manlove, Mittal, S.: Size versus stability in the marriage problem. Theoretical Computer Science 411(16), 1828–1841 (2010)
  • [8] Biró, P., Irving, R.W., Manlove, D.: Popular matchings in the marriage and roommates problems. In: 7th International Conference on Algorithms and Complexity CIAC. pp. 97–108 (2010)
  • [9] Brandl, F., Kavitha, T.: Popular matchings with multiple partners. In: Proceedings of 37th IARCS Annual Conference on Foundations of Software Technology and Theoretical Computer Science. pp. 19:1–19:15 (2017)
  • [10] Cseh, Á.: Trends in computational social choice. pp. 105 – 122. COST (European Cooperation in Science and Technology) (2017)
  • [11]

    Cseh, Á., Kavitha, T.: Popular Edges and Dominant Matchings. In: Proceedings of the Eighteenth Conference on Integer Programming and Combinatorial Optimization. pp. 138–151 (2016)

  • [12] Gale, D., Shapley, L.: College Admissions and the Stability of Marriage. American Mathematical Monthly 69, 9–14 (1962)
  • [13] Gusfield, D., Irving, R.W.: The Stable Marriage Problem: Structure and Algorithms. MIT Press (1989)
  • [14] Hamada, K., Iwama, K., Miyazaki, S.: The Hospitals/Residents Problem with Lower Quotas. Algorithmica 74(1), 440–465 (2016)
  • [15] Immorlica, N., Mahdian, M.: Marriage, honesty, and stability. In: Proceedings of the 16th Annual ACM-SIAM Symposium on Discrete Algorithms. pp. 53–62 (2005)
  • [16] Kavitha, T.: A Size-Popularity Tradeoff in the Stable Marriage Problem. SIAM Journal on Computing 43(1), 52–71 (2014)
  • [17] Manlove, D.F., McBride, I., Trimble, J.: “Almost-stable” matchings in the Hospitals / Residents problem with Couples. Constraints 22(1), 50–72 (2017)
  • [18] Nasre, M., Nimbhorkar, P.: Popular matchings with lower quotas. In: Proceedings of 37th IARCS Annual Conference on Foundations of Software Technology and Theoretical Computer Science. pp. 44:1–44:15 (2017)
  • [19] Nasre, M., Rawat, A.: Popularity in the generalized hospital residents setting. In: Proceedings of the 12th International Computer Science Symposium in Russia. pp. 245–259 (2017)
  • [20] Yokoi, Y.: Envy-free matchings with lower quotas. In: Proceedings of the 28th International Symposium on Algorithms and Computation, ISAAC. pp. 67:1–67:12 (2017)

5 Example Instances

5.1 Instance where a stable matching is favourable over a maximum cardinality popular matching

Figure 2: Example instance in which stable matching matches more residents to their rank-1 hospitals than the maximum cardinality popular matching .

Here, we present an HR instance (in fact a stable marriage instance) which shows that (i) the stable matching in matches more residents to their rank-1 hospitals than the maximum cardinality popular matching in and (ii) more number of residents prefer over . This example shows that theoretically there are no guarantees on these parameters for a popular matching.

Let and with the preferences of the residents and hospitals as given in Figure 2. All hospitals have an upper quota of . The instance admits a unique stable matching whereas the maximum cardinality popular matching is . The stable matching matches three residents to their rank-1 hospitals whereas matches exactly one resident to its rank-1 hospital. Similarly two residents prefer over and exactly one resident prefers over .

5.2 Instance where max. cardinality popular matching is favourable over a stable matching

Consider another instance where and . All hospitals have a lower quota of 0 and upper quota of 1. The preferences of the residents and the hospitals are as given in  3. The matching is stable in the instance whereas the matching is a maximum cardinality popular matching in the instance. The matching has three residents matched to their rank-1 hospitals as opposed to which has only two residents matched to their rank-1 hospitals. Furthermore, it is easy to see that more residents prefer over than the other way.

Figure 3: Example instance in which max. cardinality popular matching matches more residents to their rank-1 hospitals than the stable matching . More residents prefer over that the other way.