Stable Marriage

INF421: Design and Analysis of Algorithms
Lecture 1: Stable Marriages

Benjamin Doerr
CV Benjamin Doerr
born in Munich
Diploma 1998 (Kiel): Group theory
PhD 2000 (Kiel): Combinatorics
Habilitation 2005 (Kiel): Algorithms
2005-2013: Senior researcher ( directeur de recherche at CNRS),

Max Planck Institute for Informatics, Saarbrcken
since Oct. 2013: Full professor for informatics,
LIX, cole Polytechnique
research area:
randomized algorithms,
evolutionary algorithms,
games,
INF421 (X'14), 1st Lecture: Stable Marriages
INF421 Team:
Marie Albenque:
coordinator of the quizzes, PC groups in French/English
Karthikeyan Bhargavan:
coordinator of the programming homeworks, PC groups in English
Luca Castelli:
coordinator of the programming project, PC groups in French
Philippe Jacquet:
PC groups in French, various internal jobs
Maks Ovsjanikov:
coordinator of the PC, PC groups in English
Coordinator: The person organizing this task by distributing the work in
the team and overlooking that everything works
the first person to ask questions, complain if things dont work, etc.
Course Organization
8 amphis (today, Nov 13 to Dec 18, Jan 8), Friday, 10:30-12:00
8 PC (Friday afternoon): practice the lecture content, training for the exam
4 homeworks (DM): practice programming, understand lecture material
also via programming
voluntary quizzes:
test if you understood the previous lecture
chance to think about the next topic
possibly (your choice) a programming project (PI)
Exam, Grading
Most of these course ingredients aim at making you learn something new
and useful use this opportunity!
Note classante (note chiffre) [0, 20]: fully determined by the contrle
classante (CC)
Note de module (note littrale) {, , }: also influenced by PI and DM
DM [2, +2], PI [0,20]
no PI: CC + DM
with PI: max{CC, (2*CC+PI)/3} + DM
the PI can only increase your grade (and often it does)
all computations done in [0,20], then transformed into {, , }
Project (PI)
Rules (for all courses):
Each course INF4, 2, offers a programming project (PI).
It is recommended that each student does one project;
a project is a prerequisite for doing a PA in informatique.
workload: programming (~20 hours / ~500 lines of code), write a report,
20min defense (10min presentation, 10min questions)
A project is a cool experience (very different from the more narrow,
more guided homeworks)
Rough plan for INF421 (details to be fixed very soon):
choice of ~5 different topics, you choose one by 11.11.
deadline for program and report: early January
defense: mid-January
Course Language
General rule: English is the course language, but no-one should suffer
from knowing English less than French.
everything graded can be done in both languages
Amphis, poly, sujet/corrig of PC and DM: English
PC classes: groups in both languages offered, you choose
Exam:
sujet given in both languages
your answers can be in either language (including a reasonable mix)
Feedback
This is the 2nd edition of INF421. The first one went very well: we did not
mess up something, friendly evaluation comments, ranked 3rd out of 12
courses of the 2nd quarter (unofficial), 23% more students this year
Our plan for this year: Improve further!
You can help us: Let us know about anything youre not happy with or
where you see room for improvement
Feedback:
Easiest and fastest: Send an email to me and/or the right coordinator
Talk to your dlgu(e)s: Each PC group has a dlgu(e), two of
them are the course dlgu(e)s
Take part in the survey(s) / evaluations
Should be elected today at
the beginning of the class. If

your teacher forgets, please
remind him/her.8
Attendance (Absentisme)
Last year: INF421 had very high attendance in the amphis and average
attendance in the PC (Friday afternoon?)
Personally, I think youre old enough to know what you do (attend or stay
away). Im happy if you come, because its more fun to teach a large class.
The official rule is that you have to attend all amphis and PCs. Excessive
absence can lead to a grade of F. Absentisme is monitored and
discussed in the end-of-quarter meeting of DE and professors.
Attendance-Grade Correlation
Data from the last course (all grades before harmonization, pre-literal =
before translation into A, , E):
Absences in PC
0
1
2
3
4
Grand total
Count
84
59
27
6
5
181
Average note chiffre

13.45357143
12.79830508
12.35185185
10.58333333
12.42
12.9519337
Average of pre-literal grade

15.48194444
14.12683616
13.40802469
9.8
12.02
14.44686924
Bottom line:
You seem to learn more and do better in the exam if you attend.
try to attend the PC despite the unlucky Friday afternoon slot!
10
Content/Target of this Course

Continuation of the algorithms material covered in INF321 or INF311+411.
[classic] More algorithms: graph algorithms, scheduling algorithms,
you know more of the very central algorithms
[classic] General algorithm design methods: divide-and-conquer, dynamic
programming, greedy algorithms
enable you to find efficient algorithms yourself
[new] Algorithmic paradigms: Algorithmic game theory, approximation
algorithms, randomized algorithms, heuristics
understand algorithmic problems and find the right type of solution
algorithmics beyond deterministic recipes computing an optimal
solution in polynomial time
11
Reasons To Study Algorithms

Algorithms are everywhere. Whenever someone/something computes
something, then it is an algorithm that enables this.
central topic of computer science
timeless (in the sense that is has been a hot topic ever since)
Algorithms is a central ingredient in the curriculum of (almost) all
international top schools/universities
people expect you to be proficient in algorithms
In an algorithms course, you not only learn algorithms, but
you also learn analyzing computer science problems with mathematical
means (theory, considered difficult)
you train your problem-solving skills
12
Topic for Today: Stable Marriages

A classic problem with a classic solution: Gale-Shapley algorithm
Shapley got the Nobel prize in economics for this
We also use it as example for
how to find algorithms
how to describe algorithms (pseudocode)
how to analyze algorithms
It leads us to the new paradigm algorithmic game theory
13
Outline of This Lecture
The stable marriage problem

Derive a first algorithm
Analyze it, understand it
Use our understanding to make it better
Summary: analyzing algorithms
Algorithmic game theory a hot topic today
14
Stable Marriage Problem
men
women
each one has a clear order of preference of the other side
task: find a stable marriage one, where no two people can both improve
their situation by breaking up and forming a new couple
Red marriages not

stable because of
dotted line!
?
1.
2.
1.
2.
1.
2.
?
1.
2.
15
Stable Marriage Problem
men
women
task: find a stable marriage one, where no two people can both improve
their situation by breaking up and forming a new couple
Stable, because no
unmarried pair
wants to get married
1.
2.
1.
2.
1.
2.
1.
2.
16
Definition: Stable Marriage Problem

Set of men, set of women

write 1 > 2 to denote that the man prefers woman 1 over 2 ; note
that > is a linear order (total order) on
same with men/women exchanged
task: find a stable marriage (matching)

matching : such that each and each occurs in
at most one pair in (no bigamy)
perfect matching : each man and woman occurs in exactly one pair
stable matching : perfect matching such that
, , > ) ( > )
no unmarried (, ) can form a couple and make both more happy
17
Finding an Algorithm Playing

With the Problem [black board]
everyone has the same preferences:
easy: the most popular man and most popular woman marry, the two
second most popular marry,
different preferences:
iterative improvement cycles
constructive: greedy approach, but in an orderly manner
18
A First Algorithm
Start with all people being single
While there is a single man do
Let be the most attractive woman (for ) that is either single or
engaged with another man less attractive to her than
if is engaged to , they split up and both become single
and become engaged
Key ideas:
Greedy approach: asks the most attractive woman he can get at that
time (tries to avoid instable pairs)
Ordered progress: Always take a single man and look for a partner for
him (tries to avoid cycles, hope that this makes analyzing the algorithm
easier)
19
Disclaimer!
We use the traditional/antique language of men, women, marrying etc.
because it is convenient and
because this is the classic way to present this material.
We do not intend to make any statement on the relation of men and
women (or men and men or women and women) in the real life.
If there are asymmetries in how our algorithms treat men and women, then
this is purely for algorithmic reasons
We do not suggest to use any of our algorithms for real-world dating
problems
20
Is This a Good Algorithm?

and become engaged
Question: Is this a good algorithm?

Termination: Does the algorithm surely stop?
Correctness: Does the algorithm do what we want (output a stable m.)?
Complexity: How long does the algorithm run?
Can we say more about its solutions than being stable?
To answer such non-trivial questions, we need a deeper understanding of
how the algorithm works (main task for today, but first something else)
21
Pseudocode vs. Real Code

and become engaged
Above: Algorithm description in rough pseudocode

advantage: less complex than Java code, we do not need to specify
irrelevant things good to understand the main ideas, good to prove
correctness and termination
disadvantage: less precise, needs work to be transformed into a
program, complexity harder to determine, risk that we overlook
important details.
22
Different Levels of Details

Textual description: Starting with all people being single, we repeat
marrying unmarried men to the most attractive women willing to marry
them, until everyone is married.
very compact
high risk of ambiguity (or strong need for the reader to think)
most attractive women means most attractive for that particular man
(because we have individual preferences)
marrying may include breaking up the existing marriages
23
Rough Pseudocode
and become engaged
Mostly relying on natural language (single, split up, )

some mathematical precision (e.g., in the definition of )
some algorithmic constructs: while-loop
intentional ambiguity: we dont specify in which order to treat the single
men if we prove that this algorithm works, we know that any order is
OK, so when implementing the algorithm, we can choose an order that is
best from the implementation point of view
24
More Precise Pseudocode

While ( , ) do
Choose with ( , )
Let be such that
: , : , > and such that
for all we have
: , : , > >
If : , then { , }
,
Output
No natural language, all mathematically precise

more algorithmic constructs: while-loop, if..then, output
missing: how to implement the maths statements, datastructures (e.g., )
25
Summary: Describing Algorithms

You have the choice between different levels of mathematical and
algorithmic precision (from plain text to Java code)
Choose the one most appropriate for your purposes!
too detailed: hard to understand, easy to make mistakes, timeconsuming
too rough: ambiguous, hard to build precise arguments on
intentional ambiguities: make clear which design choices are irrelevant
for the algorithm to work
Choosing the right level of detail is essential for efficient communication!
[also in the exam]
26
Question Zero
and become engaged
Question zero: Is this an executable algorithm at all?

Can all operations (possibly after being made more precise) be executed?
Yes .
The choice of is ambiguous, but we agreed that imprecise
statements can be made precise in an arbitrary way
All the rest is fine, except possibly the choice of (next slide)
27
Question Zero, Answer

and become engaged
Question zero: Is there always a single woman or an engaged woman that

would break up for ? (If not, we cannot execute this line)
Answer: Yes. We have the same number of men and women. Hence if
there is a single man, then there must also be a single woman.
28
How to Analyze Algos? Invariants!

and become engaged
Difficulty: When running an algorithm, variables change over time
here: the hidden variable storing the matching
makes it hard to follow what is going on.
Solution: Find simple statements that are true all the time (invariants)
Each womans situation improves (see disclaimer!) over time
single some guy better guy final partner
As a man, you never ask a women twice
29
Proving the Invariants

and become engaged
Invariant 1: Each womans partners improve over time. Proof: Look at algo.
Invariant 2: Each man asks each woman at most once
Proof: Assume asks at least once. At the first time, they become
engaged (because men [in this algo.] only ask when they have a
chance). To ask a second time, and must split up before. This only
happens if is asked by a more attractive man 1 . From that point on,
by Invariant 1, is always married to a man at least as attractive as 1 .
Hence will never ask again.
30
Invariant Termination/Complexity
and become engaged
Invariant 2: Each man asks each woman at most once.
Lemma 1: Our algorithm terminates after 2 iterations of the while-loop.

Proof: By Invariant 2, the pair (, ) such that man asks woman is
different in each iteration of the while-loop. Since there are men and
women, there are only 2 pairs at all, hence at most 2 iterations.
31
Invariants Correctness (1)

and become engaged
Invariant 3: The engaged couples form a matching
Proof (classic loop invariant):

Invariant 3 holds when first entering the while-loop (nobody engaged)
Assume that Invariant 3 holds at the start of the loop. Then it holds at the end
of the loop because (i) only the couple (, ) was newly formed, (ii) was
single, (iii) had at most one partner (Invariant 3), but if so, dumped him
before engaging with .
Invariant always holds
32

and become engaged
Invariant 3: The engaged couples form a matching

Lemma: The algo. terminates with a perfect matching of engaged couples
Proof: Termination (Lemma 1) + Matching (Invariant 3)
We saw that the algo. terminates at all.
By the termination condition of the while loop, all men are engaged.
Since the non-singles form a matching (Invariant 3), the same number
(=all) of women is engaged. Hence all are engaged: perfect matching.
33

and become engaged
Invariant 4: If and are engaged, then all women more attractive for
than are engaged with a man they find more attractive than .
Proof: Let with > . When and became engaged, was
engaged to a man with > (otherwise would have asked
instead of , see algo.). By Invariant 1, remains engaged with men more
attractive than .
34

and become engaged
Invariant 4: If and are engaged, then all women more attractive for
than are engaged with a man they find more attractive than .
Theorem: Our algorithm terminates with the engaged couples forming a
stable matching.
Proof: Lemma 2 shows perfect matching. We show stability:
Let (, ) and ( , ) be engaged. If finds more attractive than , then
by Invariant 4, prefers over . Hence forming a new couple (, ) is
not interesting for .
35
Stronger Invariants
and become engaged
Invariant 1: Womens partner improve over time.

Invariant 2: Each man asks each women at most once
Invariant 2+: The women asked by man over time are sorted in strictly
decreasing order of preference
Proof: Let 1 , 2 be two women last asked by in that order. When asked 1 , he
did not ask 2 either because 1 is more attractive (that is what we want to show),
or because 2 was married to a cooler guy than him. By Invariant 1, 2 remains
married to cooler guys, contradicting our assumption that asked her later.
37
Invariants Better Algorithm

and become engaged
Invariant 2+: The women asked by man over time are sorted in strictly
decreasing order of preference
We can use Invariant 2+ to simplify our algorithm:
currently: line 3 is costly, we have to check all women
new: we let ask all women in decreasing order (possibly getting a
negative answer).
38
Gale-Shapley Algorithm
Start
[pretty much the same as before, except that men now ask all women and possibly
are rejected (which is good, because we do not need to check this relation again)]
39
Summary: Analyzing Algorithms

Questions to be answered:
question zero: is this an executable algorithm at all?
Termination
Correctness
Complexity, typically time complexity = number of elementary
operations performed
Key approach:
extract precise properties from the algorithm
use these properties to argue with mathematical methods (e.g., proof
by contradiction)
40
Invariants vs. Temporal Properties

True invariants: (static) assertions that are valid throughout the execution
of the algorithm.
Example: the couples formed by the algorithm are a matching
advantage: static, can be checked at any time
proof technique: loop invariant (induction for computer scientists)
show: assertion true when the loop is first entered
show: if the assertion is true at the beginning of the loop, then also
at the end
gives: assertion always true
Temporal properties: (dynamic) assertions that describe the process
example: womens partners improve over time
disadvantage: can only be checked by looking at the whole process
can be transformed into static assertions ( poly)
41
Poly: Different & More

Different in the poly: Derive the true Gale-Shapley algorithm first, then
analyze it with the methods used today (not a big difference from the
amphi)
More: Prove termination via a loop variant
a non-negative counter that decreases in each iteration
More and truly worth reading (as everything in the poly ): Use invariants
to understand the solution computed by our algorithm.
best() := the (by ) most preferred woman such that there is a
stable matching having , as couple; , |
worst() := the (by ) least preferred man such that there is a stable
matching having , as couple; (), |
Theorem: The Gale-Shapley algorithms outputs =
(regardless of how we implement the ambiguous parts)
42
Algorithmic Game Theory

The stable marriage problem is a first example of what is a hot topic today:
Algorithmic game theory = Problems that have both an algorithmic and a
game theoretic flavor.
Game theory in a nutshell:
players
each player has different ways to play (strategies)
pay-offs: depending on the strategies chosen by all players
each player gains or loses something
players try to optimize their own profit (selfishness)
Solution concept: Repeatedly played games converge to a situation
where no player can improve his/her situation by changing only their
strategy (Nash equilibrium, Pareto optimum)
43
Algorithmic Game Theory

Algorithmic game theory became a hot topic in computer science recently,
because the internet produces or supports game theoretic situations:
many simultaneously acting agents (players)
anonymity: eases optimizing own profit at the cost of others
sheer mass of agents forbids more coordinated approaches other than
everyone acting independently
Examples:
Online market places (eBay)
Pricing systems for online advertisements
Shared resources, e.g., in routing
44
Example Matchings: Classic

Algorithmics vs. Game Theory
Set-up: men, women, but now each pair has a weight (happiness)
Classic algorithmics: Maximum weight matching = a matching maximizing
the sum of the happiness values
social optimum (here: 100+100)
Observation: This is not stable, the 101-pair wants to form a couple.
GT: Stable matching = no pair wants to form a new couple (Nash eq.)
100
101
100
45
Price of Anarchy
100
101
100
Price of Anarchy (PoA):

How much do we lose by not
achieving the social optimum,
but only a stable solution?
-- value of social optimum: 200
-- value of Nash equilibrium: 102
hence here: PoA 2
46
Truthfulness
Players might have an incentive to
not reveal the true problem data.
100
101
200
100
Example: If the 101-pair reports a

happiness of 200 instead, then the
social optimum changes to 200+1,
i.e., they are a couple in the social
optimum incentive to lie!
Truthfulness: The algorithm is such
that no player has an incentive to lie
47
Braesss Paradox
100 people want to drive from A to B in this network. Travel times are
constant or depend on the number of people using the edge. We
assume that repeated play lets us end up in a stable solution.
A
A
100
100
Stable solution: 50 go left and 50 right,

so everyones travel time is 50+100=150
100
0
100
Stable solution: all go -0-, so

everyones travel time is 100+0+100=200
48
Take-Home Message: ATG

Many algorithmic problems today have a game theoretic flavor: We have
to take into account individual selfish/unorganized behaviors
Consequences:
Prize of anarchy: The stable solution (Nash equilibrium) might be
worse than the globally optimal one (social optimum)
Truthfulness: We cannot rely on people revealing the true problem data
need for truthful algorithms, where no player wants to lie
Many other unexpected things like an additional road increases the
traffic jams
When designing algorithms for real problems, we have to be aware of
game theoretic aspects in our problem otherwise, we might compute
solutions that are optimal in some mathematical sense, but do not work
in practice!
49
What Next?
Lunch
PC today 13:30-15:30 or 15:45-17:45
Read the poly (everything we did today precisely written up, Gale-Shapley
is good for men and unfair to women, truthful auctions: pay only the
second-highest bid).
Homework (DM): Implement the Gale-Shapley algorithm in Java. Details on
the Moodle. Deadline 11.11.
Watch out for infos (mail/Moodle) on the programming project. Again, no
action required before 11.11.
See you Friday in 3 weeks with Divide and Conquer: computing the
median without sorting, finding closest points in the plane,
50

Stable Marriage

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Stable Marriage

Uploaded by

Copyright:

Available Formats

INF421: Design and Analysis of Algorithms

Lecture 1: Stable Marriages

2005-2013: Senior researcher ( directeur de recherche at CNRS),

INF421 (X'14), 1st Lecture: Stable Marriages

INF421 (X'14), 1st Lecture: Stable Marriages

INF421 (X'14), 1st Lecture: Stable Marriages

the beginning of the class. If

INF421 (X'14), 1st Lecture: Stable Marriages

Average note chiffre

Average of pre-literal grade

INF421 (X'14), 1st Lecture: Stable Marriages

Content/Target of this Course

Reasons To Study Algorithms

INF421 (X'14), 1st Lecture: Stable Marriages

Topic for Today: Stable Marriages

INF421 (X'14), 1st Lecture: Stable Marriages

Outline of This Lecture

The stable marriage problem

INF421 (X'14), 1st Lecture: Stable Marriages

Stable Marriage Problem

Red marriages not

Stable Marriage Problem

Definition: Stable Marriage Problem

each one has a clear order of preference of the other side

task: find a stable marriage (matching)

Finding an Algorithm Playing

INF421 (X'14), 1st Lecture: Stable Marriages

INF421 (X'14), 1st Lecture: Stable Marriages

INF421 (X'14), 1st Lecture: Stable Marriages

Is This a Good Algorithm?

Question: Is this a good algorithm?

Pseudocode vs. Real Code

Above: Algorithm description in rough pseudocode

Different Levels of Details

INF421 (X'14), 1st Lecture: Stable Marriages

Mostly relying on natural language (single, split up, )

INF421 (X'14), 1st Lecture: Stable Marriages

More Precise Pseudocode

No natural language, all mathematically precise

Summary: Describing Algorithms

INF421 (X'14), 1st Lecture: Stable Marriages

Question zero: Is this an executable algorithm at all?

Question Zero, Answer

Question zero: Is there always a single woman or an engaged woman that

INF421 (X'14), 1st Lecture: Stable Marriages

How to Analyze Algos? Invariants!

Proving the Invariants

Lemma 1: Our algorithm terminates after 2 iterations of the while-loop.

Invariants Correctness (1)

Proof (classic loop invariant):

Invariants Correctness (2)

Invariant 3: The engaged couples form a matching

Invariants Correctness (3)

Invariants Correctness (3)

Invariant 1: Womens partner improve over time.

INF421 (X'14), 1st Lecture: Stable Marriages

Invariants Better Algorithm

Summary: Analyzing Algorithms

INF421 (X'14), 1st Lecture: Stable Marriages

Invariants vs. Temporal Properties

Poly: Different & More

INF421 (X'14), 1st Lecture: Stable Marriages

Algorithmic Game Theory

INF421 (X'14), 1st Lecture: Stable Marriages