Stable Marriage

Benjamin Doerr

Lecture 1: Stable Marriages

INF421: Design and Analysis of Algorithms

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, Saarbrücken since Oct. 2013: Full professor for informatics,

LIX, École Polytechnique

research area: randomized algorithms, evolutionary algorithms, games, …

CV Benjamin Doerr

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

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 don’t work, etc.

INF421 Team:


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 chiffrée) ∈ [0, 20]: fully determined by the contrôle classante (CC)

Note de module (note littérale) ∈ {𝐴, … ,𝐸}: 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 you’re 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 délégué(e)s: Each PC group has a délégué(e), two of

them are the course délégué(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.

Attendance (Absentéisme)

Last year: INF421 had very high attendance in the amphis and average attendance in the PC (Friday afternoon?)

Personally, I think you’re old enough to know what you do (attend or stay away). I’m happy if you come, because it’s 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”. Absentéisme 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):

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!


Absences in PC Count Average note chiffrée Average of pre-literal grade 0 84 13.45357143 15.48194444 1 59 12.79830508 14.12683616 2 27 12.35185185 13.40802469 3 6 10.58333333 9.8 4 5 12.42 12.02 Grand total 181 12.9519337 14.44686924

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” INF421 (X'14), 1st Lecture: Stable Marriages 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


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”


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


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


1. 2.

1. 2.

2. 1.

2. 1.

?

?

Red marriages not stable because of

dotted line!

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


1. 2.

1. 2.

2. 1.

2. 1.

Stable, because no unmarried pair

wants to get married

Definition: Stable Marriage Problem

Set 𝐺 of 𝑛 men, set 𝐹 of 𝑛 women

each one has a clear order of preference of the other side 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”


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


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)


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


Is This a Good Algorithm?




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…) INF421 (X'14), 1st Lecture: Stable Marriages 21

Pseudocode vs. Real Code




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.


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


Rough Pseudocode




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 don’t 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


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., 𝑀)


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, time-

consuming 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]


Question Zero




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) INF421 (X'14), 1st Lecture: Stable Marriages 27

Question Zero, Answer




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.


How to Analyze Algo’s? Invariants!




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 woman’s situation improves (see disclaimer!) over time

single some guy better guy … final partner As a man, you never ask a women twice


Proving the Invariants




Invariant 1: Each woman’s 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.


Invariant Termination/Complexity




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.


Invariants Correctness (1)




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






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.






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 𝑔.






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 𝑓𝑔. INF421 (X'14), 1st Lecture: Stable Marriages 35

Stronger Invariants




Invariant 1: Women’s 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.


Invariants Better Algorithm




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).


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)]

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)


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: “women’s partners improve over time” disadvantage: can only be checked by looking at the whole process can be transformed into static assertions ( poly)


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) INF421 (X'14), 1st Lecture: Stable Marriages 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)


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


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

100

101 1

Example Matchings: Classic Algorithmics vs. Game Theory

Price of Anarchy




100

100

101 1 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

Truthfulness




100

100

101 1

Players might have an incentive to not reveal the true problem data. 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

200

Braess’s 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 let’s us end up in a stable solution.


A

B

100

100

𝑥

𝑥

Stable solution: 50 go left and 50 right, so everyone’s travel time is 50+100=150

A

B

100

100

𝑥

𝑥

Stable solution: all go “𝑥-0-𝑥”, so everyone’s travel time is 100+0+100=200

0

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! INF421 (X'14), 1st Lecture: Stable Marriages 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, … INF421 (X'14), 1st Lecture: Stable Marriages 50

Stable Marriage

Documents

Transcript of Stable Marriage