Superstability in the StudentProject Allocation Problem with Ties
Abstract
The StudentProject Allocation problem with lecturer preferences over Students (SPAS) involves assigning students to projects based on student preferences over projects, lecturer preferences over students, and the maximum number of students that each project and lecturer can accommodate. This classical model assumes that preference lists are strictly ordered. Here, we study a generalisation of SPAS where ties are allowed in the preference lists of students and lecturers, which we refer to as the StudentProject Allocation problem with lecturer preferences over Students with Ties (SPAST). We investigate stable matchings under the most robust definition of stability in this context, namely superstability. We describe the first polynomialtime algorithm to find a superstable matching or to report that no such matching exists, given an instance of SPAST. Our algorithm runs in time, where is the total length of all the preference lists. Finally, we present results obtained from an empirical evaluation of the lineartime algorithm based on randomlygenerated SPAST instances. Our main finding is that, whilst superstable matchings can be elusive, the probability of such a matching existing is significantly higher if ties are restricted to the lecturers’ preference lists.
Keywords:
studentproject allocation problem, stable matching, superstability, blocking pair, polynomialtime algorithm, empirical evaluation1 Introduction
The StudentProject Allocation problem (SPA) [16, 6] involves sets of students, projects and lecturers, where students are to be assigned to projects offered by lecturers. Applications of SPA can be found in many university departments, for example, the School of Computing Science, University of Glasgow [15], the Faculty of Science, University of Southern Denmark [6], the Department of Computing Science, University of York [14], and elsewhere [3, 5, 8]. In this setting, lecturers provide a list of projects, and students are required to rank a subset of these projects that they find acceptable, in order of preference. Typically there may be upper bounds on the number of students that each project and lecturer can accommodate. Considering the preferences and the capacities of projects and lecturers, the problem then is to find a matching, which is an assignment of students to projects such that each student is assigned at most one project, and the capacity constraints on projects and lecturers are not violated, that is optimal in some sense according to the stated preferences.
In this work, we will concern ourselves with a variant of SPA that involves lecturer preferences over students, which is known as the StudentProject Allocation problem with lecturer preferences over Students (SPAS). In this context, it has been argued [21] that a natural property for a matching to satisfy is that of stability. Informally, a stable matching ensures that no student and lecturer who are not matched together would rather be assigned to each other than remain with their current assignees. Such a pair have an incentive to form a private arrangement outside of the matching, undermining its integrity. Other variants of SPA in the literature involve lecturer preferences over their proposed projects [13, 18, 19], lecturer preferences over (student, project) pairs [2], and no lecturer preferences at all [15]. See [6] for a detailed recent survey.
The classical SPAS model assumes that preferences are strictly ordered. However, this might not be achievable in practice. For instance, a lecturer may be unable or unwilling to provide a strict ordering of all the students who find her projects acceptable. Such a lecturer may be happier to rank two or more students equally in a tie, which indicates that the lecturer is indifferent between the students concerned. This leads to a generalisation of SPAS which we refer to as the StudentProject Allocation problem with lecture preferences over Students with Ties (SPAST). If we allow ties in the preference lists of students and lecturers, different stability definitions arise naturally. Suppose is a matching in an instance of SPAST. Informally, we say is weakly stable, strongly stable or superstable if there is no student and lecturer such that if they decide to form an arrangement outside the solution, respectively,

both of them would be better off,

one of them would be better off and the other no worse off,

neither of them would be worse off.
With respect to this informal definition, clearly a superstable matching is strongly stable, and a strongly stable matching is weakly stable. These concepts were first defined and studied by Irving [9] in the context of the Stable Marriage problem with Ties, and subsequently extended to the Hospitals/Residents problem with Ties (HRT) [10, 11] (where HRT is the special case of SPAST in which each lecturer offers only one project, and the capacity of each project is the same as the capacity of the lecturer offering the project).
Considering the weakest of the three stability concepts mentioned above, every instance of SPAST admits a weakly stable matching (this follows by breaking the ties in an arbitrary fashion and applying the stable matching algorithm described in [1] to the resulting SPAS instance). However, such matchings could be of different sizes [17]. Thus opting for weak stability leads to the problem of finding a weakly stable matching that matches as many students to projects as possible – a problem that is known to be NPhard [12, 17], even for the socalled Stable Marriage problem with Ties and Incomplete lists, which is the special case of hrt in which each project (hospital) has capacity 1.
Choosing superstability avoids this problem, because (i) analogous to the HRT case, all superstable matchings have the same size [10], (ii) finding one or reporting that none exists can be accomplished in lineartime (as we will see in this paper), and (iii) if a superstable matching exists then all weakly stable matchings are of the same size (equal to the size of ), and match exactly the same set of students (see Sect. 2.2 for proof). Furthermore, Irving et al. argued in [10] that superstability is a very natural solution concept in cases where agents have incomplete information. Central to their argument is the following proposition, stated for hrt in [10, Proposition 2], which extends naturally to spast as follows (see Sect. 2.2 for a proof). {restatable}[]propositionsuperstability Let be an instance of SPAST, and let be a matching in . Then is superstable in if and only if is stable in every instance of SPAS obtained from by breaking the ties in some way. In a practical setting, suppose that a student has incomplete information about two or more projects and decides to rank them equally in a tie , and a superstable matching exists in the corresponding SPAST instance , where is assigned to a project in . Then is stable in every instance of spas (obtained from by breaking the ties) that represents the true preferences of . Consequently, we will focus on the concept of superstability in the SPAST context.
Unfortunately not every instance of SPAST admits a superstable matching. This is true, for example, in the case where there are two students, two projects and one lecturer, where the capacity of each project is , capacity of the lecturer is , and every preference list is a single tie of length 2. Nonetheless, it should be clear from the discussion above that a superstable matching should be preferred in practical applications when one does exist.
Irving et al. [10] described an algorithm to find a superstable matching given an instance of HRT, or to report that no such matching exists. However, merely reducing an instance of SPAST to an instance of HRT and applying the algorithm described in [10] to the resulting HRT instance does not work in general (we explain this further in Sect. 2.3).
Our Contribution. In this paper, we describe the first polynomialtime algorithm to find a superstable matching or to report that no such matching exists, given an instance of SPAST – thus solving an open problem given in [1, 16]. Our algorithm runs in time linear in the size of the problem instance. The remaining sections of this paper are structured as follows. We give a formal definition of the SPAS problem, the SPAST variant, and the superstability concept in Sect. 2. We describe our algorithm for SPAST under superstability in Sect. 3. Further, Sect. 3 also presents our algorithm’s correctness results and some structural properties satisfied by the set of superstable matchings in an instance of SPAST. In Sect. 4, we present results arising from an empirical evaluation that investigates how the nature of the preference lists would affect the likelihood of a superstable matching existing, with respect to randomlygenerated SPAST instances. Our main finding is that the probability of a superstable matching existing is significantly higher if ties are restricted to the lecturers’ preference lists. Finally, Sect. 5 presents some concluding remarks and potential direction for future work.
2 Preliminary definitions
2.1 Formal definition of SpaS
An instance I of SPAS involves a set of students, a set of projects and a set of lecturers. Each student ranks a subset of in strict order. We denote by the ranked set of projects that finds acceptable. We say that finds acceptable if .
Each lecturer offers a nonempty set of projects , where partitions . Lecturer provides a preference list, which we denote by , ranking in strict order of preference those students who find at least one project in acceptable. Also has a capacity , indicating the number of students she is willing to supervise. Similarly each project has a capacity indicating the maximum number of students that can be assigned to this project.
We assume that for any lecturer , (i.e., the capacity of is (i) at least the highest capacity of the projects offered by , and (ii) at most the sum of the capacities of all the projects is offering). We denote by , the projected preference list of lecturer for , which can be obtained from by removing those students that do not find acceptable (thereby retaining the order of the remaining students from ).
An assignment is a subset of such that implies that finds acceptable. If , we say that is assigned to , and is assigned . For convenience, if is assigned in to , where is offered by , we may also say that is assigned to , and is assigned .
For any student , we let denote the set of projects assigned to in . For any project , we denote by the set of students assigned to in . Project is undersubscribed, full or oversubscribed according as is less than, equal to, or greater than , respectively. Similarly, for any lecturer , we denote by the set of students assigned to in . Lecturer is undersubscribed, full or oversubscribed according as is less than, equal to, or greater than , respectively.
A matching is an assignment such that each student is assigned to at most one project in , each project is assigned at most students in , and each lecturer is assigned at most students in . If is assigned to some project in , for convenience we let denote that project.
Definition 1 (stability)
Let be an instance of spas, and let be a matching in . We say is stable if it admits no blocking pair, where a blocking pair is an acceptable pair such that (a) is either unassigned in or prefers to , and (b) either

is undersubscribed and is undersubscribed, or

is undersubscribed, is full and either , or prefers to the worst student in , or

is full and prefers to the worst student in ,
where is the lecturer who offers .
To find a stable matching in an instance of SPAS, two lineartime algorithms were described in [1]. The stable matching produced by the first algorithm is studentoptimal (that is, each student has the bestpossible project that they could obtain in any stable matching) while the one produced by the second algorithm is lectureroptimal (that is, each lecturer has the best set of students that they could obtain in any stable matching). The set of studentoptimal stable matchings in a given instance of SPAS satisfy several interesting properties that together form what we will call the Unpopular Lecturers Theorem (analogous to the Rural Hospitals Theorem for HR [10]), which we state as follows.
Theorem 2.1 ([1])
For a given instance of SPAS, the following holds.

Each lecturer is assigned the same number of students in all stable matchings

Exactly the same students are unassigned in all stable matchings

A project offered by an undersubscribed lecturer is assigned the same number of students in all stable matchings
2.2 Ties in the preference lists
We now define formally the generalisation of SPAS in which preference lists can include ties. In the preference list of lecturer , a set of students forms a tie of length if does not prefer to for any (i.e., is indifferent between and ). A tie in a student’s preference list is defined similarly. For convenience, in what follows we consider a nontied entry in a preference list as a tie of length one. We denote by SPAST the generalisation of SPAS in which the preference list of each student (respectively lecturer) comprises a strict ranking of ties, each comprising one or more projects (respectively students).
An example SPAST instance I is given in Fig. 1, which involves the set of students , the set of projects and the set of lecturers . Ties in the preference lists are indicated by round brackets.
Student preferences  Lecturer preferences  
:  : ( )  offers , 
: ( )  :  offers 
:  
:  Project capacities:  
:  Lecturer capacities: 
In the context of SPAST, we assume that all notation and terminology carries over from Sect. 2.1 as defined for SPAS with the exception of stability, which we now define. When ties appear in the preference lists, three levels of stability arise (as in the HRT context [10, 11]), namely weak stability, strong stability and superstability. The formal definition for weak stability in SPAST follows from the definition for stability in SPAS (see Definition 1). Moreover, the existence of a weakly stable matching in an instance of SPAST is guaranteed by breaking the ties in arbitrarily, thus giving rise to an instance of spas. Clearly, a stable matching in is weakly stable in . Indeed a converse of sorts holds, which gives rise to the following proposition. {restatable}[]propositionweakstability Let be an instance of SPAST, and let be a matching in . Then is weaklystable in if and only if is stable in some instance of SPAS obtained from by breaking the ties in some way.
Proof
Let be an instance of spast and let be a matching in . Suppose is weakly stable in . Let be an instance of spas obtained from by breaking the ties in the following way. For each student in such that the preference list of includes a tie containing two or more projects, we order the preference list of in as follows: if is assigned in to a project in then prefers to every other project in ; otherwise, we order the projects in arbitrarily. For each lecturer in such that ’s preference list includes a tie , if contains students that are assigned to in and students that are not assigned to in , then ’s preference list in is ordered in such a way that each in such that is better than each in such that ; otherwise, we order the students in arbitrarily. Now, suppose forms a blocking pair for in Given how the ties in were removed to obtain , this implies that forms a blocking pair for in , a contradiction to our assumption that is weakly stable in . Thus is stable in .
Conversely, suppose is stable in some instance of spas obtained from by breaking the ties in some way. Now suppose that is not weakly stable in . Then some pair forms a blocking pair for in . It is then clear from the definition of weak stability and from the construction of that is a blocking pair for in , a contradiction. ∎
As mentioned earlier, superstability is the most robust concept to seek in a practical setting. Only if no superstable matching exists in the underlying problem instance should other forms of stability be sought. Thus, for the remainder of this paper, we focus on superstability in the SPAST context.
Definition 2 (superstability)
Given an instance I of SPAST, a matching in I is superstable if admits no blocking pair, where an acceptable pair is a blocking pair of if: (a) either is unassigned in or prefers to or is indifferent between them; and (b) either

is undersubscribed and is undersubscribed, or

is undersubscribed, is full, and either or prefers to the worst student in or is indifferent between them, or

is full and prefers to the worst student in or is indifferent between them,
where is the lecturer who offers . It may be verified that the matching is superstable in Fig. 1. Clearly, a superstable matching is weakly stable. Moreover, the superstability definition gives rise to Proposition 1, which we restate as follows. \superstability*
Proof
Let be an instance of spast and let be a matching in . Suppose is superstable in . We want to show that is stable in every instance of spas obtained from by breaking the ties in some way. Now, let be an arbitrary instance of spas obtained from by breaking the ties in some way, and suppose is not stable in . This implies that admits a blocking pair in . Since is an arbitrary spas instance obtained from by breaking the ties in some way, it follows that in : (i) if is assigned in then either prefers to or is indifferent between them, (ii) if is full in then either prefers to a worst student in or is indifferent between them, and (iii) if is full in then either or prefers to a worst student in or is indifferent between them. This implies that forms a blocking pair for in , a contradiction to the superstability of .
Conversely, suppose is stable in every instance of spas obtained from by breaking the ties in some way. Now suppose is not superstable in . This implies that admits a blocking pair in . We construct an instance of spas from by breaking the ties in the following way: (i) if is assigned in and is indifferent between and in then prefers to in ; otherwise we break the ties in ’s preference list arbitrarily, and (ii) if some student, say , different from is assigned to in such that is indifferent between and in then prefers to in ; otherwise we break the ties in ’s preference list arbitrarily. Thus forms a blocking pair for in , i.e., is not stable in , a contradiction to the fact that is stable in every instance of spas obtained from by breaking the ties in some way. ∎
The following proposition, which is a consequence of Propositions 1 and 2.2, and Theorem 2.1, tells us that if a superstable matching exists in then all weakly stable matchings in are of the same size (equal to the size of ) and match exactly the same set of students. {restatable}[]propositionallinone Let be an instance of SPAST, and suppose that admits a superstable matching . Then the Unpopular Lecturers Theorem holds for the set of weakly stable matchings in .
2.3 Cloning from SpaSt to Hrt does not work
A lineartime algorithm for HRT under superstability was described in [10]. One might assume that reducing a given instance of SPAST to an instance of HRT (using a “cloning” technique) and subsequently applying the algorithm described in [10] to the resulting instance would solve our problem. However, this is not always true. In what follows, we describe an obvious method to clone an instance of SPAST to an instance of HRT, and we show that applying the superstable matching algorithm described in [10] to the resulting HRT instance does not work in general.
A method to derive an instance of HRT from an instance of SPAST was described by F. Cooper (personal communication to S. Olaosebikan, December 2017). We briefly explain this method as follows. The students involved are converted into residents and the projects are converted into hospitals. Residents inherit their preference lists naturally from students. Hospitals inherit their preference lists from the projected preference list of the associated project according to the lecturer offering the project. Each hospital also inherits its capacity from the project. However, in order to translate the lecturer’s capacity into the HRT instance, we create dummy residents for each lecturer , where is the difference between the sum of the capacities of all the projects is offering and the capacity of . The preference list for each of these dummy residents will be a single tie consisting of all the hospitals associated with the projects offered by , and the preference lists for each hospital will include a tie in its first position consisting of all the dummy residents associated with .
3 An algorithm for SpaSt under superstability
In this section we present our algorithm for SPAST under superstability, which we will refer to as Algorithm SPASTsuper. First, we note that our algorithm is a nontrivial extension of Algorithm SPAstudent for spas from [1] and Algorithm HRTSuperRes for hrt from [10]. Due to the more general setting of SPAST, Algorithm SPASTsuper requires some new ideas, and the proofs of the correctness results are more complex than for the aforementioned algorithms for spas and hrt. In Sect. 3.1, we give a description of our algorithm, before presenting it in pseudocode form. In Sect. 3.2, we illustrate an execution of our algorithm with respect to an example SPAST instance. We present the algorithm’s correctness results in Sect. 3.3. Finally, in Sect. 3.4, we show that the set of superstable matchings in an instance of SPAST satisfy several structural properties.
3.1 Description of the algorithm
First, we present some definitions relating to the algorithm. In what follows, I is an instance of SPAST, is an acceptable pair in I and is the lecturer who offers . Further, if belongs to some superstable matching in I, we call a superstable pair and a superstable partner of (and viceversa).
During the execution of the algorithm, students become provisionally assigned to projects. It is possible for a project to be provisionally assigned a number of students that exceed its capacity. This holds analogously for a lecturer. The algorithm proceeds by deleting from the preference lists certain pairs that cannot be superstable. By the term delete , we mean the removal of from ’s preference list and the removal of from (the projected preference list of lecturer for ). In addition, if is provisionally assigned to at this point, we break the assignment. By the head of a student’s preference list at a given point, we mean the set of one or more projects, tied in her preference list after any deletions might have occurred, that she prefers to all other projects in her list.
For project , we define the tail of as the leastpreferred tie in after any deletions might have occurred (recalling that a tie can be of length one). In the same fashion, we define the tail of (preference list of lecturer ) as the leastpreferred tie in after any deletions might have occurred. If is provisionally assigned to , we define the successors of in as those students that are worse than in . An analogous definition holds for the successors of in .
We now describe our algorithm. Algorithm SPASTsuper begins by initialising an empty set which will contain the provisional assignments of students to projects (and intuitively to lecturers). We remark that such assignments can subsequently be broken during the algorithm’s execution. Also, each project is initially assigned to be empty (i.e., not assigned to any student).
The while loop of the algorithm involves each student who is not provisionally assigned to any project in and who has a nonempty list applying in turn to each project at the head of her list. Immediately, becomes provisionally assigned to in (and to ). If, by gaining a new student, becomes oversubscribed, it turns out that none of the students at the tail of can be assigned to in any superstable matching – such pairs are deleted. Similarly, if by gaining a new student, becomes oversubscribed, none of the students at the tail of can be assigned to any project offered by in any superstable matching – such pairs , for each project that finds acceptable, are deleted.
Regardless of whether any deletions occurred as a result of the two conditionals described in the previous paragraph, we have two further (possibly nondisjoint) cases in which deletions may occur. If becomes full, we let be any worst student provisionally assigned to (according to ), and we delete for each successor of in . Similarly if becomes full, we let be any worst student provisionally assigned to , and we delete , for each successor of in and for each project that finds acceptable. As we will prove later, none of the (student, project) pairs deleted when a project or a lecturer becomes full can be a superstable pair.
At the point where the while loop terminates (i.e., when every student is provisionally assigned to one or more projects or has an empty list), if some project that was previously full ends up undersubscribed, we let be any one of the most preferred students (according to ) who was provisionally assigned to during some iteration of the algorithm but is not assigned to at this point (for convenience, we henceforth refer to such as the most preferred student rejected from according to ). If the students at the tail of (recalling that the tail of is the leastpreferred tie in after any deletions might have occurred) are no better than , it turns out that none of these students can be assigned to any project offered by in any superstable matching – such pairs , for each project that finds acceptable, are deleted. The while loop is then potentially reactivated, and the entire process continues until every student is provisionally assigned to a project or has an empty list.
At the termination of the repeatuntil loop, if the set , containing the provisional assignments of students to projects, is superstable relative to the given instance I then is output as a superstable matching in I. Otherwise, the algorithm reports that no superstable matching exists in I. We present Algorithm SPASTsuper in pseudocode form in Algorithm 1.
3.2 Example algorithm execution
We illustrate an execution of Algorithm SPASTsuper with respect to the SPAST instance shown in Fig. 1 on Page 1. We initialise , which will contain the provisional assignment of students to projects. For each project , we set full() = false (full() will be set to true when becomes full; thus we can easily identify any project which was full during an iteration of the algorithm and ended up undersubscribed). We assume that the students become provisionally assigned to each project at the head of their list in subscript order. Table 1 illustrates how this execution of Algorithm SPASTsuper proceeds with respect to .
while loop iterations  Student applies to project  Consequence 

applies to  . full() = true.  
applies to  . becomes oversubscribed. The tail of contains and – thus we delete the pairs and (and intuitively, we break the provisional assignments).  
applies to  . full() = true.  
applies to  .  
applies to  . full() = true.  
applies to  . becomes oversubscribed. The tail of contains only – thus we delete the pair (and intuitively, we break the provisional assignment).  
The first iteration of the while loop terminates since every unassigned student (that is, and ) has an empty list. Now, at this point full() is true and is undersubscribed. Moreover, the student at the tail of (that is, ) is no better than , where is the most preferred student rejected from according to ; thus we delete the pair . The while loop is then reactivated.  
applies to  . becomes oversubscribed. The tail of contains only – thus we delete the pair .  
applies to  .  
Again, every unassigned students has an empty list. We also have that full() is true and is undersubscribed; however no further deletion is carried out in line 33 of the algorithm, since the student at the tail of (that is, ) is better than , where is the most preferred student rejected from according to . Hence, the repeatuntil loop terminates and the algorithm outputs as a superstable matching. It is clear that is superstable in the original instance . 
3.3 Correctness of Algorithm SpaStsuper
We now present the following results regarding the correctness of Algorithm SPASTsuper. The first of these results deals with the fact that no superstable pair is ever deleted during the execution of the algorithm. In what follows, I is an instance of SPAST, is an acceptable pair in I and is the lecturer who offers . {restatable}[]lemmanopairdeletion If a pair is deleted during the execution of Algorithm SPASTsuper, then does not belong to any superstable matching in I. In order to prove Lemma 3.3, we present Lemmas 1 and 2.
Lemma 1
If a pair is deleted within the while loop during the execution of Algorithm SPASTsuper, then does not belong to any superstable matching in I.
Proof
Without loss of generality, suppose that the first superstable pair to be deleted within the while loop during an arbitrary execution of the algorithm is , which belongs to some superstable matching, say . Let be the lecturer who offers . Suppose that is the assignment immediately after the deletion. Let us denote this point in the algorithm where the deletion is made by . During , there are four cases that would lead to the deletion of any (student, project) pair within the while loop. In what follows, we consider each case.
Case 1  is oversubscribed. Suppose that is deleted because some student (possibly ) became provisionally assigned to during , causing to become oversubscribed. If is full or undersubscribed at point , since and no project can be oversubscribed in , then there is some student such that either prefers to or is indifferent between them. We note that cannot be assigned to a project that she prefers to in any superstable matching as this would mean a superstable pair must have been deleted before , as must be in the head of ’s list when she applied. Thus either is unassigned in , or prefers to or is indifferent between them. Clearly, for any combination of and being full or undersubscribed in , it follows that blocks , a contradiction.
Case 2  is oversubscribed.
Suppose that is deleted because some student (possibly ) became provisionally assigned to a project offered by lecturer during , causing to become oversubscribed. At point , none of the projects offered by is oversubscribed in , otherwise we will be in Case 1. Similar to Case 1, if is full or undersubscribed at point , since and no lecturer can be oversubscribed in , it follows that there is some project and some student . We consider two subcases. If , then . Moreover, as in Case 1, either is unassigned in , or prefers to or is indifferent between them. For any combination of and being full or undersubscribed in , since prefers to or is indifferent between them, it follows that blocks , a contradiction. If . Assume firstly that . Then as has fewer assignees in than it has provisional assignees in and as in (i) above, blocks , a contradiction. Finally assume . Then must have applied to at some point during before . Clearly, prefers to or is indifferent between them, since must have been in the head of ’s list when applied. Since and is undersubscribed in , we have that blocks , a contradiction.Case 3  is full.
Suppose that is deleted because became full during . At point , is full in . Thus at least one of the students in , say will not be assigned in , for otherwise will be oversubscribed in . This implies that either is unassigned in , or prefers to or is indifferent between them. For otherwise we obtain a contradiction to being the first superstable pair to be deleted. Since prefers to , it follows that blocks , a contradiction.Case 4  is full.
Suppose that is deleted because became full during . We consider two subcases. All the students assigned to in at point (if any) are also assigned to in . This implies that has one more assignee in than it has provisional assignees in , namely . Thus, some other project has fewer assignees in than it has provisional assignees in , for otherwise would be oversubscribed in . Hence there exists some student . It is clear that since plays the role of in line 32 of the algorithm at some for loop iteration. Also, cannot be assigned to a project that she prefers to in , as explained in Case 1. Hence, since is undersubscribed in and prefers to , blocks , a contradiction. Some student, say , assigned to in is not assigned in , that is, . Since cannot be assigned a project that she prefers to in and prefers to , this implies blocks , a contradiction. ∎Lemma 2
If a pair is deleted outside the while loop of Algorithm SPASTsuper, then does not belong to any superstable matching in I.
Proof
Without loss of generality, suppose that the first superstable pair to be deleted during an aribitrary execution of the algorithm is , which belongs to some superstable matching, say . Then by Lemma 1, was deleted outside of the while loop during . Let be the lecturer who offers . Suppose that is the assignment immediately after the termination of the most recent while loop.
Let be some other project offered by which was full during an iteration of the while loop and subsequently ends up undersubscribed at the end of the while loop, that is plays the role of in line 27. Suppose that plays the role of in line 29, that is was the most preferred student rejected from according to (possibly ). Then prefers to or is indifferent between them, since plays the role of at some for loop iteration in line 31. Moreover was provisionally assigned to during an iteration of the while loop but at the end of the while loop. Thus , since no superstable pair is deleted within the while loop, as proved in Lemma 1.
Again, none of the students assigned to some project in can be assigned any project better than their provisional project in any superstable matching as this would mean a superstable pair must have been deleted before , as each student apply to projects in the head of their list. So, either is unassigned in or prefers to or is indifferent between them. By the superstability of , is full in and prefers the worst student in to , for if is undersubscribed in then blocks since prefers to or is indifferent between them, a contradiction.
Let , and . Just before the deletion of occured, is undersubscribed in . Since is full in , it follows that there exists some student . We note that prefers to .
Since is the first superstable pair to be deleted, is assigned in a project such that prefers to or is indifferent between them. For otherwise, as students apply to projects in the head of their list, that would mean must have been deleted during an iteration of the while loop, a contradiction. We note that , since and .
Let be the lecturer who offers . By the superstability of , it follows that either

is full in and prefers a worst student in to , or

is undersubscribed in , is full in , and prefers a worst student in to .
Otherwise, blocks . In case (a), there exists some student . Let . In case (b), there exists some student . We note that prefers to . We suppose (possibly ).
Clearly . Applying similar reasoning as for , is assigned in a project such that prefers to or is indifferent between them. Let be the lecturer who offers .
We are identifying a sequence of students, sequence of projects and sequence of lecturers, such that for each

prefers to or is indifferent between them,

offers and offers both and (possibly ),

prefers to .
First we claim that for each new project we identify, for . Suppose