WEBVTT 00:00:00.000 --> 00:00:02.460 align:middle line:90% [SQUEAKING] 00:00:02.460 --> 00:00:04.428 align:middle line:90% [RUSTLING] 00:00:04.428 --> 00:00:07.380 align:middle line:90% [CLICKING] 00:00:07.380 --> 00:00:10.340 align:middle line:90% 00:00:10.340 --> 00:00:11.730 align:middle line:90% ZACHARY ABEL: Good morning. 00:00:11.730 --> 00:00:12.950 align:middle line:90% Welcome back. 00:00:12.950 --> 00:00:15.163 align:middle line:90% Today is Lecture 12. 00:00:15.163 --> 00:00:16.580 align:middle line:84% We are continuing our Graph Theory 00:00:16.580 --> 00:00:20.960 align:middle line:84% unit, this time talking about matchings and stable matchings. 00:00:20.960 --> 00:00:23.720 align:middle line:84% Matchings, in general, are a really useful concept 00:00:23.720 --> 00:00:24.720 align:middle line:90% in graph theory. 00:00:24.720 --> 00:00:26.960 align:middle line:84% They come up frequently when you're trying 00:00:26.960 --> 00:00:30.900 align:middle line:90% to match pairs of objects. 00:00:30.900 --> 00:00:33.680 align:middle line:84% You want everyone to have one partner or possibly 00:00:33.680 --> 00:00:34.467 align:middle line:90% zero partners. 00:00:34.467 --> 00:00:36.300 align:middle line:84% If they don't get a match, then they're sad. 00:00:36.300 --> 00:00:37.910 align:middle line:90% That's fine. 00:00:37.910 --> 00:00:39.870 align:middle line:84% But matchings are a really useful concept, 00:00:39.870 --> 00:00:44.150 align:middle line:84% so let's talk about what they mean, what they're good at, 00:00:44.150 --> 00:00:46.560 align:middle line:84% and a few ideas surrounding these. 00:00:46.560 --> 00:00:51.170 align:middle line:90% So first of all, definition. 00:00:51.170 --> 00:00:57.010 align:middle line:90% A matching in a graph-- 00:00:57.010 --> 00:01:01.070 align:middle line:90% 00:01:01.070 --> 00:01:03.810 align:middle line:84% which, remember, has a set of vertices and a set of edges 00:01:03.810 --> 00:01:06.890 align:middle line:90% which are pairs of vertices-- 00:01:06.890 --> 00:01:15.660 align:middle line:90% is a subgraph, M-- 00:01:15.660 --> 00:01:17.660 align:middle line:84% and what subgraph means is we're just 00:01:17.660 --> 00:01:23.930 align:middle line:84% taking a subset of the vertices and a subset of the edges, 00:01:23.930 --> 00:01:29.090 align:middle line:84% so long as all the edges have their vertices in the subset-- 00:01:29.090 --> 00:01:48.170 align:middle line:84% in which every vertex in V has degree less equal to 1 in M. 00:01:48.170 --> 00:01:48.680 align:middle line:90% I'm sorry. 00:01:48.680 --> 00:01:53.480 align:middle line:84% This is vertex set of our subset. 00:01:53.480 --> 00:01:56.810 align:middle line:84% Said differently-- a different definition which is just 00:01:56.810 --> 00:01:57.750 align:middle line:90% as good-- 00:01:57.750 --> 00:02:11.340 align:middle line:84% a matching is a subset of the edges of our graph 00:02:11.340 --> 00:02:21.425 align:middle line:84% where no two selected edges share an endpoint. 00:02:21.425 --> 00:02:24.990 align:middle line:90% 00:02:24.990 --> 00:02:27.670 align:middle line:84% So we're just choosing some of the edges of our graph, 00:02:27.670 --> 00:02:29.820 align:middle line:84% making sure that we never touch edges that 00:02:29.820 --> 00:02:31.830 align:middle line:90% have an endpoint in common. 00:02:31.830 --> 00:02:39.790 align:middle line:84% For example, I can draw this bow-tie-looking graph, this, 00:02:39.790 --> 00:02:44.340 align:middle line:84% this, this, this, this, here, here, here, and here. 00:02:44.340 --> 00:02:51.970 align:middle line:84% And then vertex a, b, c, d, e, f, g, h. 00:02:51.970 --> 00:02:54.660 align:middle line:84% So if this is our graph, let me give you 00:02:54.660 --> 00:02:56.780 align:middle line:90% an example of a matching. 00:02:56.780 --> 00:02:59.610 align:middle line:84% So an example of a matching is M. 00:02:59.610 --> 00:03:04.795 align:middle line:84% This is going to be just the edges be and dg. 00:03:04.795 --> 00:03:08.210 align:middle line:90% 00:03:08.210 --> 00:03:11.480 align:middle line:84% This is an alternative notation for edges, by the way. 00:03:11.480 --> 00:03:15.330 align:middle line:84% Instead of writing the set b comma e close curly brace, 00:03:15.330 --> 00:03:17.120 align:middle line:84% I can just write be next to each other 00:03:17.120 --> 00:03:19.440 align:middle line:84% and it's clear we're talking about those two vertices. 00:03:19.440 --> 00:03:21.840 align:middle line:84% So we're dealing with the edge, be-- 00:03:21.840 --> 00:03:23.870 align:middle line:90% so that's this edge-- 00:03:23.870 --> 00:03:25.670 align:middle line:90% and the edge, dg-- 00:03:25.670 --> 00:03:28.520 align:middle line:90% which is this edge. 00:03:28.520 --> 00:03:29.575 align:middle line:90% Is this a matching? 00:03:29.575 --> 00:03:36.320 align:middle line:90% 00:03:36.320 --> 00:03:38.850 align:middle line:90% I see some head nods. 00:03:38.850 --> 00:03:41.750 align:middle line:84% Yeah, this is a matching because none of our selected edges 00:03:41.750 --> 00:03:43.410 align:middle line:90% have endpoints in common. 00:03:43.410 --> 00:03:46.580 align:middle line:90% If I had also chosen edge fd-- 00:03:46.580 --> 00:03:49.080 align:middle line:84% if I'd tried to put fd into there as well-- 00:03:49.080 --> 00:03:50.840 align:middle line:84% then these two edges would be in conflict 00:03:50.840 --> 00:03:53.270 align:middle line:84% and we would no longer have a matching. 00:03:53.270 --> 00:03:54.780 align:middle line:90% Does that make sense? 00:03:54.780 --> 00:03:57.910 align:middle line:84% So said more similar to our first definition, 00:03:57.910 --> 00:04:00.060 align:middle line:84% if we look at just the subgraph that includes 00:04:00.060 --> 00:04:02.970 align:middle line:84% our chosen edges, all of the vertices 00:04:02.970 --> 00:04:05.850 align:middle line:84% in that subgraph need to have degree at most 1. 00:04:05.850 --> 00:04:10.140 align:middle line:84% So this has degree 1 and 1 and 1 and 1 and 0s for the others. 00:04:10.140 --> 00:04:11.845 align:middle line:84% If we have edges sharing endpoints, 00:04:11.845 --> 00:04:14.345 align:middle line:84% we'd have higher degree, which is not allowed in a matching. 00:04:14.345 --> 00:04:18.660 align:middle line:90% 00:04:18.660 --> 00:04:20.790 align:middle line:84% Like I said, this has lots of applications anytime 00:04:20.790 --> 00:04:23.560 align:middle line:84% we're trying to pair things up, for example, 00:04:23.560 --> 00:04:25.860 align:middle line:90% online dating services. 00:04:25.860 --> 00:04:30.390 align:middle line:84% You're trying to recommend, say, this user to that user 00:04:30.390 --> 00:04:31.890 align:middle line:84% and you recommend them to each other 00:04:31.890 --> 00:04:34.620 align:middle line:84% and they go on a date or something like that. 00:04:34.620 --> 00:04:36.840 align:middle line:84% And maybe you want to try to match up a bunch of them 00:04:36.840 --> 00:04:39.940 align:middle line:84% at once so you can have lots of dates happening in parallel. 00:04:39.940 --> 00:04:43.090 align:middle line:84% So you want a matching that includes lots of edges, 00:04:43.090 --> 00:04:47.700 align:middle line:84% knowing that no one can go on multiple dates at once. 00:04:47.700 --> 00:04:50.960 align:middle line:84% Sometimes you might have a bunch of tasks 00:04:50.960 --> 00:04:55.180 align:middle line:84% in an expensive computational project. 00:04:55.180 --> 00:04:57.240 align:middle line:84% You have lots of tasks you need to do 00:04:57.240 --> 00:04:59.830 align:middle line:84% and lots of servers that can help you out in parallel, 00:04:59.830 --> 00:05:02.440 align:middle line:84% but each server can only do one job at a time. 00:05:02.440 --> 00:05:04.770 align:middle line:84% So you want to find a matching that 00:05:04.770 --> 00:05:07.200 align:middle line:84% gets lots of servers working on different tasks 00:05:07.200 --> 00:05:08.580 align:middle line:90% at the same time. 00:05:08.580 --> 00:05:10.260 align:middle line:84% So you want to find a matching that 00:05:10.260 --> 00:05:14.490 align:middle line:84% includes lots of your servers and lots of your tasks 00:05:14.490 --> 00:05:16.230 align:middle line:84% and find a matching with lots of edges 00:05:16.230 --> 00:05:17.990 align:middle line:84% so you get lots done in parallel. 00:05:17.990 --> 00:05:21.090 align:middle line:90% 00:05:21.090 --> 00:05:23.280 align:middle line:84% So in a lot of these examples, we're 00:05:23.280 --> 00:05:26.710 align:middle line:84% trying to maximize the number of edges in our matching, 00:05:26.710 --> 00:05:29.620 align:middle line:84% try to get lots and lots of pairings all at once. 00:05:29.620 --> 00:05:31.650 align:middle line:84% And there are a couple of different notions 00:05:31.650 --> 00:05:36.120 align:middle line:84% of big, a big matching, a matching with lots of edges 00:05:36.120 --> 00:05:37.450 align:middle line:90% that we want to define. 00:05:37.450 --> 00:05:41.050 align:middle line:84% We want to define a maximal matching and a maximum matching. 00:05:41.050 --> 00:05:43.120 align:middle line:84% And I'm sorry that those sound very similar. 00:05:43.120 --> 00:05:45.090 align:middle line:84% But let's talk about what they mean. 00:05:45.090 --> 00:06:03.290 align:middle line:84% So we'll say that M is a maximal matching when it's not 00:06:03.290 --> 00:06:12.750 align:middle line:84% possible to find another edge that's in our set 00:06:12.750 --> 00:06:21.170 align:middle line:84% but not yet in our matching such that M with that new edge 00:06:21.170 --> 00:06:22.045 align:middle line:90% is matching. 00:06:22.045 --> 00:06:25.040 align:middle line:90% 00:06:25.040 --> 00:06:28.730 align:middle line:84% So maximal means you can't add new edges to the set of edges 00:06:28.730 --> 00:06:30.440 align:middle line:90% you already have. 00:06:30.440 --> 00:06:33.860 align:middle line:84% So in this case, with these two edges, 00:06:33.860 --> 00:06:37.760 align:middle line:84% all of the other edges I might try to add to these two 00:06:37.760 --> 00:06:40.560 align:middle line:84% have an endpoint in common with one or the other. 00:06:40.560 --> 00:06:44.630 align:middle line:84% So I can't pick new edges to put into M while keeping the ones I 00:06:44.630 --> 00:06:45.830 align:middle line:90% already have. 00:06:45.830 --> 00:06:48.843 align:middle line:84% So that makes M, this matching is maximal. 00:06:48.843 --> 00:06:54.260 align:middle line:90% 00:06:54.260 --> 00:06:55.230 align:middle line:90% Does that make sense? 00:06:55.230 --> 00:06:57.680 align:middle line:84% This is a local notion where all you 00:06:57.680 --> 00:07:00.150 align:middle line:84% have to do is look at the matching you have and ask 00:07:00.150 --> 00:07:03.810 align:middle line:84% is there any single other edge that I can put in here as well. 00:07:03.810 --> 00:07:06.830 align:middle line:84% And if there isn't, then it's maximal. 00:07:06.830 --> 00:07:09.200 align:middle line:84% And if it's not if there is another edge you 00:07:09.200 --> 00:07:11.760 align:middle line:84% can put in, well, go ahead and put it in, then search again. 00:07:11.760 --> 00:07:14.130 align:middle line:84% If there's yet another edge you can put in, put it in. 00:07:14.130 --> 00:07:16.130 align:middle line:84% Keep going until there isn't, and then you 00:07:16.130 --> 00:07:17.700 align:middle line:90% have a maximal matching. 00:07:17.700 --> 00:07:20.220 align:middle line:84% So it's very easy to find a maximal matching. 00:07:20.220 --> 00:07:23.270 align:middle line:84% You just keep adding edges until you can't. 00:07:23.270 --> 00:07:26.360 align:middle line:84% The difference is that that maximal matching you find 00:07:26.360 --> 00:07:29.960 align:middle line:84% might not be the biggest matching possible ever. 00:07:29.960 --> 00:07:33.410 align:middle line:84% And that's the other notion we want-- 00:07:33.410 --> 00:07:36.020 align:middle line:90% a maximum matching. 00:07:36.020 --> 00:07:48.530 align:middle line:84% We'll say that M is a maximum matching when there does not 00:07:48.530 --> 00:07:54.800 align:middle line:84% exist a bigger matching, a matching M 00:07:54.800 --> 00:07:58.585 align:middle line:90% prime with more edges. 00:07:58.585 --> 00:08:01.880 align:middle line:90% 00:08:01.880 --> 00:08:05.820 align:middle line:84% So this is a global measure of maximum. 00:08:05.820 --> 00:08:08.300 align:middle line:84% We'll say a matching is maximum when it's 00:08:08.300 --> 00:08:10.130 align:middle line:90% the biggest you can ever do. 00:08:10.130 --> 00:08:13.140 align:middle line:84% I don't care if you keep these particular edges. 00:08:13.140 --> 00:08:15.080 align:middle line:84% Just is there any matching at all 00:08:15.080 --> 00:08:19.520 align:middle line:84% anywhere that has more edges than this? 00:08:19.520 --> 00:08:22.530 align:middle line:84% So that's the difference between maximal and maximum. 00:08:22.530 --> 00:08:24.570 align:middle line:90% Maximal is about local search-- 00:08:24.570 --> 00:08:26.510 align:middle line:84% can you make a single improvement 00:08:26.510 --> 00:08:28.100 align:middle line:90% by adding a single thing here? 00:08:28.100 --> 00:08:33.169 align:middle line:84% Maximum is a global property-- is it the biggest possible ever? 00:08:33.169 --> 00:08:36.919 align:middle line:84% And as you can imagine, finding a maximum matching 00:08:36.919 --> 00:08:39.590 align:middle line:84% or proving that a matching you have is maximum 00:08:39.590 --> 00:08:41.073 align:middle line:90% is a lot harder than maximal. 00:08:41.073 --> 00:08:44.059 align:middle line:90% 00:08:44.059 --> 00:08:49.880 align:middle line:84% This matching up here with dg and be, is that maximum? 00:08:49.880 --> 00:08:51.140 align:middle line:90% Why not? 00:08:51.140 --> 00:08:54.080 align:middle line:84% Someone shaking their head, can you tell me? 00:08:54.080 --> 00:08:55.670 align:middle line:90% Yes. 00:08:55.670 --> 00:08:58.010 align:middle line:90% AUDIENCE: It may be bg and ce. 00:08:58.010 --> 00:09:03.937 align:middle line:84% ZACHARY ABEL: All right, ad, bg you said, and ce? 00:09:03.937 --> 00:09:04.520 align:middle line:90% AUDIENCE: Yes. 00:09:04.520 --> 00:09:06.470 align:middle line:90% ZACHARY ABEL: All right. 00:09:06.470 --> 00:09:09.860 align:middle line:90% Is a matching. 00:09:09.860 --> 00:09:11.400 align:middle line:90% And is this a matching? 00:09:11.400 --> 00:09:14.180 align:middle line:90% Let's take a look. 00:09:14.180 --> 00:09:19.160 align:middle line:84% We've got ad here, bg here, ce here. 00:09:19.160 --> 00:09:22.760 align:middle line:90% None of those circled edges-- 00:09:22.760 --> 00:09:24.930 align:middle line:84% they kind of look like coffee beans to me-- 00:09:24.930 --> 00:09:27.630 align:middle line:84% none of those coffee beans share an endpoint, 00:09:27.630 --> 00:09:29.220 align:middle line:90% so that is a matching. 00:09:29.220 --> 00:09:32.480 align:middle line:84% And since this has more edges than M up there, 00:09:32.480 --> 00:09:35.150 align:middle line:90% M is not maximum. 00:09:35.150 --> 00:09:36.240 align:middle line:90% All right? 00:09:36.240 --> 00:09:36.740 align:middle line:90% Cool. 00:09:36.740 --> 00:09:38.570 align:middle line:90% So matchings can be maximal-- 00:09:38.570 --> 00:09:41.060 align:middle line:84% locally biggest-- even if they're not maximum-- 00:09:41.060 --> 00:09:43.370 align:middle line:90% globally biggest. 00:09:43.370 --> 00:09:47.155 align:middle line:84% Is this matching maximum, or can we do even better? 00:09:47.155 --> 00:09:52.880 align:middle line:90% 00:09:52.880 --> 00:09:55.500 align:middle line:84% Oh, there was someone raising their hands in the back, 00:09:55.500 --> 00:09:56.290 align:middle line:90% but it's Brynmor. 00:09:56.290 --> 00:10:03.020 align:middle line:90% [LAUGHTER] 00:10:03.020 --> 00:10:04.770 align:middle line:84% There was someone else raising their hand, 00:10:04.770 --> 00:10:07.370 align:middle line:84% but I think they were just adjusting their glasses. 00:10:07.370 --> 00:10:10.890 align:middle line:84% All these fake-outs playing jokes on me. 00:10:10.890 --> 00:10:18.620 align:middle line:84% OK, so is this a maximum matching, or can we do better? 00:10:18.620 --> 00:10:19.320 align:middle line:90% Yes. 00:10:19.320 --> 00:10:21.470 align:middle line:84% AUDIENCE: For it to be better, we'd 00:10:21.470 --> 00:10:25.790 align:middle line:84% have to add vertices, either f or h. 00:10:25.790 --> 00:10:30.920 align:middle line:84% And since they both share d with a and c, 00:10:30.920 --> 00:10:33.740 align:middle line:84% it makes sense that we can't do that because the degree of d 00:10:33.740 --> 00:10:35.390 align:middle line:90% and c would be bigger than 1. 00:10:35.390 --> 00:10:36.390 align:middle line:90% ZACHARY ABEL: All right. 00:10:36.390 --> 00:10:40.050 align:middle line:84% So let me say that so everyone else can hear. 00:10:40.050 --> 00:10:44.480 align:middle line:84% So if we had a bigger matching, we'd have to include f or h. 00:10:44.480 --> 00:10:45.447 align:middle line:90% Is that what you said? 00:10:45.447 --> 00:10:46.030 align:middle line:90% AUDIENCE: Yes. 00:10:46.030 --> 00:10:47.860 align:middle line:90% ZACHARY ABEL: All right. 00:10:47.860 --> 00:10:50.410 align:middle line:84% And if we try to include f, then it's 00:10:50.410 --> 00:10:55.120 align:middle line:84% going to share an endpoint with ad, which is not great. 00:10:55.120 --> 00:10:58.960 align:middle line:84% So yes, that's almost exactly the logic I'm looking for. 00:10:58.960 --> 00:11:00.980 align:middle line:90% Just a slight tweak to that. 00:11:00.980 --> 00:11:03.530 align:middle line:84% When we're asking if a matching is maximum, 00:11:03.530 --> 00:11:06.100 align:middle line:84% we're not really talking about adding 00:11:06.100 --> 00:11:07.880 align:middle line:90% to this specific matching. 00:11:07.880 --> 00:11:10.100 align:middle line:84% That's the maximal side of things. 00:11:10.100 --> 00:11:13.750 align:middle line:84% So instead of comparing to what we 00:11:13.750 --> 00:11:16.060 align:middle line:84% have to this particular matching, 00:11:16.060 --> 00:11:17.950 align:middle line:84% I just want to be able to prove that there 00:11:17.950 --> 00:11:20.440 align:middle line:90% is no bigger matching at all. 00:11:20.440 --> 00:11:26.230 align:middle line:84% So what would it mean for there to be a bigger matching? 00:11:26.230 --> 00:11:36.520 align:middle line:84% A bigger matching would include, well, at least four edges, 00:11:36.520 --> 00:11:38.593 align:middle line:84% and, therefore, at least eight vertices. 00:11:38.593 --> 00:11:41.470 align:middle line:90% 00:11:41.470 --> 00:11:43.910 align:middle line:84% But we only have eight vertices, right? 00:11:43.910 --> 00:11:45.760 align:middle line:90% 1, 2, 3, 4, 5, yep. 00:11:45.760 --> 00:11:47.373 align:middle line:84% So it would include all the vertices. 00:11:47.373 --> 00:11:50.380 align:middle line:90% 00:11:50.380 --> 00:11:53.770 align:middle line:84% And any matching that includes all the vertices, in particular, 00:11:53.770 --> 00:11:55.500 align:middle line:90% includes a and f. 00:11:55.500 --> 00:11:58.780 align:middle line:90% 00:11:58.780 --> 00:12:03.050 align:middle line:84% And we can't use a and f because they would both have edges to d. 00:12:03.050 --> 00:12:04.610 align:middle line:90% There's only one way to use a. 00:12:04.610 --> 00:12:06.130 align:middle line:90% There's only one way to use f. 00:12:06.130 --> 00:12:08.510 align:middle line:84% And they both use vertex d in the middle, 00:12:08.510 --> 00:12:10.030 align:middle line:90% and we can't do that. 00:12:10.030 --> 00:12:15.190 align:middle line:84% Can't use a and f at the same time. 00:12:15.190 --> 00:12:19.570 align:middle line:90% And this is our contradiction. 00:12:19.570 --> 00:12:22.610 align:middle line:84% So if there's a bigger matching, bad stuff happens. 00:12:22.610 --> 00:12:24.530 align:middle line:84% So there doesn't exist a bigger matching. 00:12:24.530 --> 00:12:28.240 align:middle line:84% That doesn't mean these three coffee beans are the only 00:12:28.240 --> 00:12:30.430 align:middle line:90% maximum matching. 00:12:30.430 --> 00:12:31.580 align:middle line:90% There are a couple more. 00:12:31.580 --> 00:12:34.150 align:middle line:84% For example, we could replace ad with fd. 00:12:34.150 --> 00:12:35.120 align:middle line:90% That would be fine. 00:12:35.120 --> 00:12:37.780 align:middle line:84% That would be a different maximum matching. 00:12:37.780 --> 00:12:43.120 align:middle line:84% So there can be multiple maximum matchings that all necessarily 00:12:43.120 --> 00:12:46.060 align:middle line:90% have to have the same size. 00:12:46.060 --> 00:12:48.760 align:middle line:84% Different maximal matchings don't all 00:12:48.760 --> 00:12:50.390 align:middle line:90% have to have the same size. 00:12:50.390 --> 00:12:54.380 align:middle line:84% As we saw, this two-edge matching is maximal, 00:12:54.380 --> 00:12:56.703 align:middle line:84% and also this three-edge matching is maximal. 00:12:56.703 --> 00:12:59.500 align:middle line:90% 00:12:59.500 --> 00:13:01.450 align:middle line:84% Does that distinction make sense? 00:13:01.450 --> 00:13:02.860 align:middle line:90% Wonderful. 00:13:02.860 --> 00:13:03.630 align:middle line:90% All right. 00:13:03.630 --> 00:13:07.140 align:middle line:90% 00:13:07.140 --> 00:13:07.640 align:middle line:90% Let's see. 00:13:07.640 --> 00:13:08.896 align:middle line:90% So next definition. 00:13:08.896 --> 00:13:14.530 align:middle line:90% 00:13:14.530 --> 00:13:25.900 align:middle line:84% A matching is perfect if and only if it includes 00:13:25.900 --> 00:13:29.110 align:middle line:90% all vertices. 00:13:29.110 --> 00:13:31.300 align:middle line:84% So a perfect matching gives everyone 00:13:31.300 --> 00:13:35.770 align:middle line:84% a partner and, therefore, exactly one partner. 00:13:35.770 --> 00:13:39.820 align:middle line:84% Does this graph have a perfect matching? 00:13:39.820 --> 00:13:40.640 align:middle line:90% No. 00:13:40.640 --> 00:13:43.750 align:middle line:84% A perfect matching would need all eight vertices 00:13:43.750 --> 00:13:44.900 align:middle line:90% and, therefore, four edges. 00:13:44.900 --> 00:13:46.608 align:middle line:84% But we already saw there are no matchings 00:13:46.608 --> 00:13:48.350 align:middle line:90% with four edges in this graph. 00:13:48.350 --> 00:13:51.130 align:middle line:84% So not all graphs are going to have perfect matchings. 00:13:51.130 --> 00:13:54.910 align:middle line:84% But often in your task allocation problems 00:13:54.910 --> 00:13:59.470 align:middle line:84% where you're trying to match everyone to another resource, 00:13:59.470 --> 00:14:01.480 align:middle line:84% ideally, you'll end up with a perfect matching 00:14:01.480 --> 00:14:06.130 align:middle line:84% where everyone gets a partner or every task gets a server. 00:14:06.130 --> 00:14:11.040 align:middle line:84% And so perfect matchings are very commonly the goal. 00:14:11.040 --> 00:14:13.840 align:middle line:90% 00:14:13.840 --> 00:14:15.850 align:middle line:84% Now, so far we've been talking about matchings 00:14:15.850 --> 00:14:17.620 align:middle line:90% in general graphs. 00:14:17.620 --> 00:14:20.410 align:middle line:84% But matchings are very common, especially 00:14:20.410 --> 00:14:24.026 align:middle line:84% in bipartite graphs, so bipartite matchings. 00:14:24.026 --> 00:14:32.380 align:middle line:90% 00:14:32.380 --> 00:14:35.470 align:middle line:84% So when we're trying to match tasks to servers, 00:14:35.470 --> 00:14:37.520 align:middle line:90% we have a bipartite graph. 00:14:37.520 --> 00:14:39.850 align:middle line:84% All the edges connect a task to a server 00:14:39.850 --> 00:14:42.810 align:middle line:84% when it's possible for that task to be done on that server. 00:14:42.810 --> 00:14:45.310 align:middle line:84% And then we're looking for a matching, which tells you which 00:14:45.310 --> 00:14:47.500 align:middle line:90% servers are doing which tasks. 00:14:47.500 --> 00:14:49.480 align:middle line:84% So a lot of problems that involve matchings 00:14:49.480 --> 00:14:52.570 align:middle line:90% are naturally bipartite. 00:14:52.570 --> 00:14:53.560 align:middle line:90% Let's see. 00:14:53.560 --> 00:14:58.760 align:middle line:84% And to emphasize, remember from last time, 00:14:58.760 --> 00:15:09.045 align:middle line:84% bipartite graphs don't need the same size on both sides. 00:15:09.045 --> 00:15:16.030 align:middle line:90% 00:15:16.030 --> 00:15:19.610 align:middle line:84% As we saw with the Harvard versus MIT bipartite graph, 00:15:19.610 --> 00:15:23.090 align:middle line:84% we had 7,000 on one side and 4,000 on the other side. 00:15:23.090 --> 00:15:37.060 align:middle line:84% Still a perfectly valid bipartite graph, however perfect 00:15:37.060 --> 00:15:46.210 align:middle line:84% matching can't possibly exist in a bipartite graph 00:15:46.210 --> 00:15:48.273 align:middle line:84% when the two sides have different sizes. 00:15:48.273 --> 00:15:55.070 align:middle line:90% 00:15:55.070 --> 00:15:57.970 align:middle line:84% There can never be a perfect matching between Harvard 00:15:57.970 --> 00:16:00.940 align:middle line:84% undergrads and MIT undergrads because there are more Harvard 00:16:00.940 --> 00:16:02.630 align:middle line:90% undergrads than MIT undergrads. 00:16:02.630 --> 00:16:04.400 align:middle line:90% Every edge includes one of each. 00:16:04.400 --> 00:16:07.570 align:middle line:84% So even if we max out all of the MIT students and give them 00:16:07.570 --> 00:16:10.150 align:middle line:84% a Harvard buddy, there are still going to be 3,000 Harvard 00:16:10.150 --> 00:16:11.650 align:middle line:90% students that lose out. 00:16:11.650 --> 00:16:14.660 align:middle line:84% So if there's a perfect matching in your bipartite graph, 00:16:14.660 --> 00:16:17.170 align:middle line:90% you have to have the same size. 00:16:17.170 --> 00:16:19.575 align:middle line:84% Doesn't mean there will always be a perfect matching when 00:16:19.575 --> 00:16:20.950 align:middle line:84% the two sides have the same size, 00:16:20.950 --> 00:16:23.470 align:middle line:90% but it's at least necessary. 00:16:23.470 --> 00:16:24.075 align:middle line:90% All right? 00:16:24.075 --> 00:16:27.340 align:middle line:90% 00:16:27.340 --> 00:16:31.250 align:middle line:84% Sometimes when you're trying to make these matchings, 00:16:31.250 --> 00:16:33.890 align:middle line:84% not only are you trying to maximize the number of pairs 00:16:33.890 --> 00:16:37.080 align:middle line:84% you get, or possibly get a perfect matching 00:16:37.080 --> 00:16:45.593 align:middle line:84% and get everyone a pair, but often edges are weighted. 00:16:45.593 --> 00:16:49.670 align:middle line:90% 00:16:49.670 --> 00:16:53.900 align:middle line:84% So each edge comes with a number. 00:16:53.900 --> 00:17:00.200 align:middle line:84% So we have a function w from the set of edges to real numbers. 00:17:00.200 --> 00:17:01.850 align:middle line:84% And each edge comes with a number. 00:17:01.850 --> 00:17:05.069 align:middle line:84% You can imagine in the task versus servers graph, 00:17:05.069 --> 00:17:07.430 align:middle line:84% each edge represents how long that task 00:17:07.430 --> 00:17:10.310 align:middle line:90% would take on that server. 00:17:10.310 --> 00:17:12.770 align:middle line:84% And maybe certain tasks are going 00:17:12.770 --> 00:17:14.849 align:middle line:84% to be faster in different servers 00:17:14.849 --> 00:17:17.280 align:middle line:84% maybe because that server is more powerful, 00:17:17.280 --> 00:17:20.819 align:middle line:84% or maybe because it's closer to other resources it might need 00:17:20.819 --> 00:17:23.300 align:middle line:84% and it can access them more quickly. 00:17:23.300 --> 00:17:26.930 align:middle line:84% But often when we have a weighted edge like this, 00:17:26.930 --> 00:17:41.100 align:middle line:84% we want a perfect matching with minimum total weight. 00:17:41.100 --> 00:17:49.570 align:middle line:90% 00:17:49.570 --> 00:17:53.953 align:middle line:84% As an example of that, here's a nice bipartite graph. 00:17:53.953 --> 00:17:57.010 align:middle line:90% 00:17:57.010 --> 00:17:59.090 align:middle line:84% And maybe this edge has weight 3. 00:17:59.090 --> 00:18:00.560 align:middle line:90% This has weight 1. 00:18:00.560 --> 00:18:01.940 align:middle line:90% This has weight 5. 00:18:01.940 --> 00:18:04.390 align:middle line:90% And this has weight 2. 00:18:04.390 --> 00:18:08.680 align:middle line:84% And I can see two different perfect matchings in this graph. 00:18:08.680 --> 00:18:12.670 align:middle line:90% There's the one that does this. 00:18:12.670 --> 00:18:16.005 align:middle line:84% And there's the one that does this. 00:18:16.005 --> 00:18:19.000 align:middle line:90% 00:18:19.000 --> 00:18:21.340 align:middle line:90% I think that's all of them. 00:18:21.340 --> 00:18:24.830 align:middle line:84% And if we look at the weights, well, this has weight 3 and 2, 00:18:24.830 --> 00:18:27.280 align:middle line:90% so this has total weight 5. 00:18:27.280 --> 00:18:33.490 align:middle line:84% And this has weight 1 and 5, so this has total weight 6. 00:18:33.490 --> 00:18:36.770 align:middle line:84% So you'd prefer this one to that one because 5 is smaller than 6. 00:18:36.770 --> 00:18:38.860 align:middle line:84% The total weight in this perfect matching 00:18:38.860 --> 00:18:42.340 align:middle line:84% is better than the total weight in this perfect matching. 00:18:42.340 --> 00:18:46.090 align:middle line:84% So these are just very common kinds of questions 00:18:46.090 --> 00:18:48.130 align:middle line:84% that you find yourself asking when 00:18:48.130 --> 00:18:51.040 align:middle line:84% you're modeling something in terms of matchings or perfect 00:18:51.040 --> 00:18:51.980 align:middle line:90% matchings. 00:18:51.980 --> 00:18:54.190 align:middle line:84% Often, there's more to optimize than just 00:18:54.190 --> 00:18:55.970 align:middle line:90% finding a perfect matching. 00:18:55.970 --> 00:19:00.850 align:middle line:84% And I mentioned all of these variations on these problems 00:19:00.850 --> 00:19:04.810 align:middle line:84% because unlike last time where we saw that graph coloring is 00:19:04.810 --> 00:19:07.820 align:middle line:84% a useful abstraction but hard to compute exactly 00:19:07.820 --> 00:19:11.860 align:middle line:84% or hard to compute optimally, all of the matching problems 00:19:11.860 --> 00:19:15.280 align:middle line:84% I've mentioned, we do have efficient algorithms for. 00:19:15.280 --> 00:19:29.890 align:middle line:84% So we have we can find maximum matchings in graphs, 00:19:29.890 --> 00:19:31.910 align:middle line:90% bipartite or otherwise. 00:19:31.910 --> 00:19:32.410 align:middle line:90% Yes. 00:19:32.410 --> 00:19:32.860 align:middle line:90% Question. 00:19:32.860 --> 00:19:34.130 align:middle line:84% AUDIENCE: A question about the weights. 00:19:34.130 --> 00:19:35.230 align:middle line:90% Are they just arbitrary? 00:19:35.230 --> 00:19:37.820 align:middle line:84% Like did you just pick those, or did they come from somewhere? 00:19:37.820 --> 00:19:38.710 align:middle line:90% ZACHARY ABEL: Oh. 00:19:38.710 --> 00:19:40.870 align:middle line:84% Yeah, where did these weights come from? 00:19:40.870 --> 00:19:43.370 align:middle line:84% These are just arbitrary in this example, 00:19:43.370 --> 00:19:45.760 align:middle line:84% I just picked them for demonstration. 00:19:45.760 --> 00:19:47.740 align:middle line:84% In a real-world scenario, the weights 00:19:47.740 --> 00:19:51.520 align:middle line:84% would represent how much work it takes to do the task 00:19:51.520 --> 00:19:54.940 align:middle line:84% corresponding to this pairing, or how expensive this is, 00:19:54.940 --> 00:19:57.082 align:middle line:90% or how desirable. 00:19:57.082 --> 00:19:58.540 align:middle line:84% So usually, these weights are going 00:19:58.540 --> 00:20:01.600 align:middle line:84% to come from whatever context you're modeling 00:20:01.600 --> 00:20:03.490 align:middle line:90% and trying to optimize for. 00:20:03.490 --> 00:20:07.240 align:middle line:84% But yeah, in this example, I just picked them. 00:20:07.240 --> 00:20:09.760 align:middle line:84% But there is an algorithm to find maximum matchings 00:20:09.760 --> 00:20:11.900 align:middle line:90% in graphs, bipartite or not. 00:20:11.900 --> 00:20:12.555 align:middle line:90% Doesn't matter. 00:20:12.555 --> 00:20:20.020 align:middle line:90% 00:20:20.020 --> 00:20:21.940 align:middle line:84% And because we can find maximum matchings, 00:20:21.940 --> 00:20:24.200 align:middle line:84% we can find perfect matchings if they exist. 00:20:24.200 --> 00:20:26.470 align:middle line:84% If a perfect matching exists, it's certainly maximum 00:20:26.470 --> 00:20:29.920 align:middle line:84% because you can't use more than that number of edges. 00:20:29.920 --> 00:20:40.200 align:middle line:84% We can find min-weight perfect matchings in bipartite graphs. 00:20:40.200 --> 00:20:44.290 align:middle line:90% 00:20:44.290 --> 00:20:47.600 align:middle line:84% We have algorithms to solve these kinds of problems. 00:20:47.600 --> 00:20:49.870 align:middle line:84% So if you ever find yourself modeling a question 00:20:49.870 --> 00:20:52.030 align:middle line:84% with matching, trying to find a matching 00:20:52.030 --> 00:20:54.580 align:middle line:84% with certain properties, very often, 00:20:54.580 --> 00:20:57.170 align:middle line:84% there will be algorithms to solve it quickly. 00:20:57.170 --> 00:20:59.998 align:middle line:84% We're not going to cover those algorithms in this class. 00:20:59.998 --> 00:21:02.040 align:middle line:84% You'll see more of them in the follow-up classes. 00:21:02.040 --> 00:21:05.440 align:middle line:90% 6.121 and 122. 00:21:05.440 --> 00:21:07.000 align:middle line:84% But just know that they're out there 00:21:07.000 --> 00:21:10.390 align:middle line:84% and know that this is a useful tool, both for modeling 00:21:10.390 --> 00:21:12.340 align:middle line:90% and for computing. 00:21:12.340 --> 00:21:14.670 align:middle line:84% Are there questions about these kinds of things? 00:21:14.670 --> 00:21:21.250 align:middle line:90% 00:21:21.250 --> 00:21:21.980 align:middle line:90% All right. 00:21:21.980 --> 00:21:24.310 align:middle line:90% No questions. 00:21:24.310 --> 00:21:27.160 align:middle line:84% Then let's move on to the main topic 00:21:27.160 --> 00:21:29.166 align:middle line:84% for today, which is stable matchings. 00:21:29.166 --> 00:21:32.570 align:middle line:90% 00:21:32.570 --> 00:21:34.316 align:middle line:84% So the topic is stable matchings. 00:21:34.316 --> 00:21:41.043 align:middle line:90% 00:21:41.043 --> 00:21:42.460 align:middle line:84% In this problem, we're going to be 00:21:42.460 --> 00:21:44.800 align:middle line:84% looking for certain kinds of perfect matchings 00:21:44.800 --> 00:21:46.810 align:middle line:90% in bipartite graphs. 00:21:46.810 --> 00:21:50.140 align:middle line:84% So in the specific scenario, let's imagine 00:21:50.140 --> 00:21:57.026 align:middle line:84% we have n applicants and n evaluators. 00:21:57.026 --> 00:21:59.740 align:middle line:90% 00:21:59.740 --> 00:22:02.920 align:middle line:84% You can think of these like n interns that are looking 00:22:02.920 --> 00:22:06.820 align:middle line:84% for managers, and n managers where we're going to match them 00:22:06.820 --> 00:22:10.480 align:middle line:84% up one to one-- each intern gets one manager and vice versa-- 00:22:10.480 --> 00:22:14.440 align:middle line:84% and we're trying to find a way to match them nicely. 00:22:14.440 --> 00:22:18.460 align:middle line:84% You can think of these as the applicants are recently 00:22:18.460 --> 00:22:20.710 align:middle line:84% graduated medical school students 00:22:20.710 --> 00:22:25.150 align:middle line:90% looking for residencies. 00:22:25.150 --> 00:22:27.040 align:middle line:84% And I mentioned this example specifically 00:22:27.040 --> 00:22:29.800 align:middle line:84% because the algorithm we're about to talk about 00:22:29.800 --> 00:22:32.860 align:middle line:90% is used in precisely that way. 00:22:32.860 --> 00:22:37.000 align:middle line:84% In practice, in the real world, in the United States at least, 00:22:37.000 --> 00:22:40.930 align:middle line:84% all residency applicants submit their list 00:22:40.930 --> 00:22:42.760 align:middle line:84% of preferences about which hospitals 00:22:42.760 --> 00:22:45.160 align:middle line:84% they want to do their residencies at. 00:22:45.160 --> 00:22:47.200 align:middle line:84% And they do interviews, and hospitals 00:22:47.200 --> 00:22:51.460 align:middle line:84% submit their preferences for which candidates they prefer. 00:22:51.460 --> 00:22:56.500 align:middle line:84% And they send this all to a national nonprofit organization 00:22:56.500 --> 00:22:59.990 align:middle line:84% who does a big global computation to find, 00:22:59.990 --> 00:23:03.580 align:middle line:84% in some sense, the best perfect matching it can. 00:23:03.580 --> 00:23:07.210 align:middle line:84% And then it notifies everyone on the same day. 00:23:07.210 --> 00:23:09.280 align:middle line:84% All the residency applicants are told 00:23:09.280 --> 00:23:12.010 align:middle line:84% on Match Day which was actually just a few weeks ago. 00:23:12.010 --> 00:23:13.580 align:middle line:90% It happens once a year. 00:23:13.580 --> 00:23:15.740 align:middle line:84% They're told where they're doing their residency. 00:23:15.740 --> 00:23:19.180 align:middle line:84% And it's a big party, and many of them 00:23:19.180 --> 00:23:21.230 align:middle line:84% are excited about going at their top school. 00:23:21.230 --> 00:23:22.980 align:middle line:84% Many of them don't get their top school, 00:23:22.980 --> 00:23:27.140 align:middle line:84% and they're still happy because they still get to be a doctor. 00:23:27.140 --> 00:23:29.870 align:middle line:84% But they're going to use exactly the algorithm I'm 00:23:29.870 --> 00:23:32.940 align:middle line:84% about to describe with some tweaks 00:23:32.940 --> 00:23:34.700 align:middle line:84% because the real world is more complicated 00:23:34.700 --> 00:23:38.660 align:middle line:84% than the simple math we're about to describe. 00:23:38.660 --> 00:23:43.680 align:middle line:84% But this is a real algorithm with real consequences. 00:23:43.680 --> 00:23:51.850 align:middle line:84% It was invented in 1962 by Gale and Shapley. 00:23:51.850 --> 00:23:57.380 align:middle line:90% 00:23:57.380 --> 00:23:58.560 align:middle line:90% That's two people. 00:23:58.560 --> 00:24:02.150 align:middle line:84% I'm going to call it the Gale-Shapley algorithm. 00:24:02.150 --> 00:24:06.290 align:middle line:84% It was also improved many years later by Al Roth. 00:24:06.290 --> 00:24:09.200 align:middle line:84% Together, they have found many real-world applications 00:24:09.200 --> 00:24:11.690 align:middle line:90% and improvements. 00:24:11.690 --> 00:24:19.250 align:middle line:84% And it won them the 2012 Nobel Prize in Economics for Al Roth 00:24:19.250 --> 00:24:22.580 align:middle line:84% and for Shapley, I don't know where Gale was in all of this. 00:24:22.580 --> 00:24:25.130 align:middle line:84% I don't think he got the Prize as well. 00:24:25.130 --> 00:24:30.940 align:middle line:84% Anyway, really important, useful, practical algorithm 00:24:30.940 --> 00:24:34.000 align:middle line:84% that actually has some fairly simple 00:24:34.000 --> 00:24:35.470 align:middle line:84% mathematical underpinnings, enough 00:24:35.470 --> 00:24:37.810 align:middle line:84% that we can describe it and analyze it and prove 00:24:37.810 --> 00:24:41.290 align:middle line:84% things about it in the next hour we have together. 00:24:41.290 --> 00:24:44.870 align:middle line:90% So what is this algorithm? 00:24:44.870 --> 00:24:46.010 align:middle line:90% What is it for? 00:24:46.010 --> 00:24:50.800 align:middle line:84% So as I said before, we have n applicants and n evaluators. 00:24:50.800 --> 00:24:56.455 align:middle line:84% And each of them is going to give a preference ordering 00:24:56.455 --> 00:25:00.520 align:middle line:84% for all n of the opposite parties in order 00:25:00.520 --> 00:25:02.060 align:middle line:90% of their preference. 00:25:02.060 --> 00:25:21.640 align:middle line:84% So all applicants and evaluators give a full ranked list 00:25:21.640 --> 00:25:23.186 align:middle line:90% of their preferences. 00:25:23.186 --> 00:25:25.900 align:middle line:90% 00:25:25.900 --> 00:25:27.413 align:middle line:90% So as a quick example-- 00:25:27.413 --> 00:25:30.910 align:middle line:90% 00:25:30.910 --> 00:25:35.590 align:middle line:84% trying not to run too fast for the cameramen back there-- 00:25:35.590 --> 00:25:40.840 align:middle line:84% so here's an example where we have five applicants and five 00:25:40.840 --> 00:25:41.803 align:middle line:90% evaluators. 00:25:41.803 --> 00:25:43.720 align:middle line:84% I haven't said, which because the relationship 00:25:43.720 --> 00:25:46.840 align:middle line:84% is pretty symmetric at this point. 00:25:46.840 --> 00:25:51.640 align:middle line:84% And so each person on the left gives a full ranked preference 00:25:51.640 --> 00:25:53.870 align:middle line:84% order for all of the people on the right. 00:25:53.870 --> 00:25:58.570 align:middle line:84% So this person A prefers H, then J, then F, then G, then I 00:25:58.570 --> 00:26:01.300 align:middle line:90% in this strict ordering. 00:26:01.300 --> 00:26:06.200 align:middle line:84% So each of these gives some permutation of F through J. 00:26:06.200 --> 00:26:08.740 align:middle line:84% Each person over here gives some permutation of A 00:26:08.740 --> 00:26:14.260 align:middle line:84% through E with no restrictions on the kinds of rankings that 00:26:14.260 --> 00:26:15.850 align:middle line:84% are allowed, as long as they give 00:26:15.850 --> 00:26:23.386 align:middle line:84% a full strict ranking of all the people, no other restrictions. 00:26:23.386 --> 00:26:25.990 align:middle line:90% 00:26:25.990 --> 00:26:29.230 align:middle line:84% If all the applicants want to choose the same evaluator 00:26:29.230 --> 00:26:30.963 align:middle line:90% as their first choice, they can. 00:26:30.963 --> 00:26:33.380 align:middle line:84% They're not all going to get it, but they can all list it. 00:26:33.380 --> 00:26:35.410 align:middle line:84% For example, if everyone really wants 00:26:35.410 --> 00:26:40.490 align:middle line:84% to come to MGH for their residency, 00:26:40.490 --> 00:26:43.240 align:middle line:84% let's live in the fiction where each hospital only 00:26:43.240 --> 00:26:45.190 align:middle line:90% gets one resident. 00:26:45.190 --> 00:26:48.130 align:middle line:84% So we're trying to match one hospital to one resident 00:26:48.130 --> 00:26:49.540 align:middle line:90% and vice versa. 00:26:49.540 --> 00:26:52.850 align:middle line:84% If everyone lists MGH as their first choice, that's fine. 00:26:52.850 --> 00:26:53.630 align:middle line:90% They can. 00:26:53.630 --> 00:26:56.590 align:middle line:90% Only one is going to get it. 00:26:56.590 --> 00:26:59.920 align:middle line:84% So no other restrictions on which permutations they give. 00:26:59.920 --> 00:27:17.770 align:middle line:84% And we want a perfect matching that leaves everyone happy-- 00:27:17.770 --> 00:27:22.030 align:middle line:90% eh, happy enough. 00:27:22.030 --> 00:27:25.190 align:middle line:84% Like I said, we can't give everyone their top choice, 00:27:25.190 --> 00:27:28.270 align:middle line:84% especially if all their top choices collide. 00:27:28.270 --> 00:27:31.390 align:middle line:84% But we want to make sure everyone's happy enough. 00:27:31.390 --> 00:27:34.150 align:middle line:84% And so let's look at an example before we describe exactly 00:27:34.150 --> 00:27:35.633 align:middle line:90% what we mean by happy enough. 00:27:35.633 --> 00:27:42.910 align:middle line:90% 00:27:42.910 --> 00:27:49.150 align:middle line:84% So let's imagine-- back to our favorite graph-- 00:27:49.150 --> 00:27:51.400 align:middle line:90% AB and CD. 00:27:51.400 --> 00:27:54.195 align:middle line:84% So we have applicants, AB, evaluators, CD. 00:27:54.195 --> 00:27:58.900 align:middle line:90% 00:27:58.900 --> 00:28:05.480 align:middle line:84% And A prefers C over D. So I'll list that as a 1 and a 2. 00:28:05.480 --> 00:28:07.750 align:middle line:84% A prefers C, and then after C, they 00:28:07.750 --> 00:28:15.130 align:middle line:84% prefer D. B likewise prefers C over D. C prefers A over B. 00:28:15.130 --> 00:28:18.790 align:middle line:90% And D also prefers A over B. 00:28:18.790 --> 00:28:21.650 align:middle line:84% If we write it out more similar to the example over there, 00:28:21.650 --> 00:28:28.980 align:middle line:84% this is saying that A prefers C over D, and B prefers C over D, 00:28:28.980 --> 00:28:37.150 align:middle line:84% and also C prefers A over B, and D prefers A over B. 00:28:37.150 --> 00:28:40.450 align:middle line:84% So we're already in a scenario where not everyone can 00:28:40.450 --> 00:28:41.450 align:middle line:90% get their top choice. 00:28:41.450 --> 00:28:45.070 align:middle line:84% Someone is going to have to take their second choice. 00:28:45.070 --> 00:28:46.490 align:middle line:90% And let's look at an example. 00:28:46.490 --> 00:28:56.140 align:middle line:84% What if we try to match AD and BC? 00:28:56.140 --> 00:28:58.270 align:middle line:90% So what's going to happen here? 00:28:58.270 --> 00:29:04.840 align:middle line:84% So A with D and B with C. So B gets C. So B is happy. 00:29:04.840 --> 00:29:07.150 align:middle line:90% B got their first choice. 00:29:07.150 --> 00:29:08.740 align:middle line:90% A with D, D is happy. 00:29:08.740 --> 00:29:11.290 align:middle line:90% D got their first choice, right? 00:29:11.290 --> 00:29:14.080 align:middle line:84% B and D have no reason to want to switch. 00:29:14.080 --> 00:29:16.540 align:middle line:90% But what about A and C? 00:29:16.540 --> 00:29:22.840 align:middle line:84% A and C are not paired together, but they each prefer each other 00:29:22.840 --> 00:29:25.600 align:middle line:90% over their assigned partners. 00:29:25.600 --> 00:29:29.950 align:middle line:84% So if you think of this as a dating scenario, 00:29:29.950 --> 00:29:32.350 align:middle line:84% if we try to say that A and D are paired 00:29:32.350 --> 00:29:35.770 align:middle line:84% and B and C are paired, then what's going to happen 00:29:35.770 --> 00:29:38.080 align:middle line:84% is that A and C are going to run away with each other 00:29:38.080 --> 00:29:40.090 align:middle line:84% because they each prefer to be with each other 00:29:40.090 --> 00:29:43.270 align:middle line:90% than their assigned partner. 00:29:43.270 --> 00:29:45.970 align:middle line:90% We call that a rogue pair. 00:29:45.970 --> 00:29:51.670 align:middle line:90% So we're going to say a pair-- 00:29:51.670 --> 00:30:02.500 align:middle line:84% so an applicant and an evaluator form a rogue pair 00:30:02.500 --> 00:30:21.160 align:middle line:84% in a matching M when E and A each prefer each other more 00:30:21.160 --> 00:30:25.830 align:middle line:90% than their assigned partner. 00:30:25.830 --> 00:30:29.513 align:middle line:90% 00:30:29.513 --> 00:30:32.180 align:middle line:84% And by the way, for the rest of lecture when I mention matching, 00:30:32.180 --> 00:30:35.488 align:middle line:84% I'm going to mean a perfect matching 00:30:35.488 --> 00:30:37.780 align:middle line:84% because we're trying to match all the applicants to all 00:30:37.780 --> 00:30:39.140 align:middle line:90% the evaluators. 00:30:39.140 --> 00:30:41.960 align:middle line:84% And if I forget to say perfect, I apologize. 00:30:41.960 --> 00:30:44.830 align:middle line:90% I mean perfect. 00:30:44.830 --> 00:30:49.810 align:middle line:84% All right, so a pair forms a rogue pair in some matching 00:30:49.810 --> 00:30:52.930 align:middle line:84% if they would each prefer each other than the partners 00:30:52.930 --> 00:30:54.910 align:middle line:84% they're assigned in that matching. 00:30:54.910 --> 00:30:57.340 align:middle line:84% And what we're going to look for, 00:30:57.340 --> 00:31:04.210 align:middle line:84% so the goal of this Gale-Shapley algorithm, 00:31:04.210 --> 00:31:17.823 align:middle line:84% we want a perfect matching with no rogue pairs. 00:31:17.823 --> 00:31:21.990 align:middle line:90% 00:31:21.990 --> 00:31:23.687 align:middle line:84% So happy enough-- we want a matching 00:31:23.687 --> 00:31:25.770 align:middle line:84% that makes everyone happy enough that you're never 00:31:25.770 --> 00:31:28.570 align:middle line:84% going to get two people running away with each other, 00:31:28.570 --> 00:31:31.020 align:middle line:84% rather than staying with their own partners. 00:31:31.020 --> 00:31:34.470 align:middle line:84% For every pair that you match up, at least one of them 00:31:34.470 --> 00:31:37.200 align:middle line:84% prefers to be with the partner they've 00:31:37.200 --> 00:31:39.810 align:middle line:84% been assigned than anyone else who would 00:31:39.810 --> 00:31:42.510 align:middle line:90% prefer to be with them. 00:31:42.510 --> 00:31:44.543 align:middle line:90% Such a matching, we call stable. 00:31:44.543 --> 00:31:52.740 align:middle line:90% 00:31:52.740 --> 00:31:55.500 align:middle line:84% So a perfect matching with no rogue pairs 00:31:55.500 --> 00:31:58.660 align:middle line:84% is what we mean by a stable matching. 00:31:58.660 --> 00:32:00.130 align:middle line:90% And that's going to be our goal. 00:32:00.130 --> 00:32:03.150 align:middle line:84% Does there always exist a stable matching? 00:32:03.150 --> 00:32:05.598 align:middle line:84% How can we find out when there does exist one? 00:32:05.598 --> 00:32:07.140 align:middle line:84% Can we come up with an algorithm that 00:32:07.140 --> 00:32:10.470 align:middle line:90% will always find one if it can? 00:32:10.470 --> 00:32:15.300 align:middle line:84% In this example, does there exist a stable matching? 00:32:15.300 --> 00:32:17.350 align:middle line:84% Well, there are only two matchings in this graph. 00:32:17.350 --> 00:32:18.790 align:middle line:90% So let's check the other one. 00:32:18.790 --> 00:32:21.910 align:middle line:84% So we saw that AD and BC is not stable. 00:32:21.910 --> 00:32:25.100 align:middle line:90% What about AC with BD? 00:32:25.100 --> 00:32:30.630 align:middle line:90% 00:32:30.630 --> 00:32:31.310 align:middle line:90% OK. 00:32:31.310 --> 00:32:35.320 align:middle line:84% So A with C, well, A and C each got their top choice. 00:32:35.320 --> 00:32:40.380 align:middle line:84% There's no way they would ever go rogue, right? 00:32:40.380 --> 00:32:44.910 align:middle line:84% And then if A and C can never go rogue, 00:32:44.910 --> 00:32:46.810 align:middle line:84% then no one can go rogue with them. 00:32:46.810 --> 00:32:50.160 align:middle line:84% So B and D isn't going to break up because B and C aren't 00:32:50.160 --> 00:32:51.610 align:middle line:90% going to run away together. 00:32:51.610 --> 00:32:52.870 align:middle line:90% C is already happy. 00:32:52.870 --> 00:32:54.880 align:middle line:84% A and D aren't going to run away together. 00:32:54.880 --> 00:32:56.820 align:middle line:90% A is already happy. 00:32:56.820 --> 00:33:06.810 align:middle line:84% So this matching is stable because none 00:33:06.810 --> 00:33:10.110 align:middle line:84% of the possible pairs are a rogue pair. 00:33:10.110 --> 00:33:13.100 align:middle line:90% Does this example make sense? 00:33:13.100 --> 00:33:13.600 align:middle line:90% Cool. 00:33:13.600 --> 00:33:16.560 align:middle line:84% So this particular example, 2 people 00:33:16.560 --> 00:33:20.160 align:middle line:84% with 2 people, each with this preference order, 00:33:20.160 --> 00:33:21.947 align:middle line:90% has a stable matching. 00:33:21.947 --> 00:33:23.780 align:middle line:84% Will there will always be a stable matching? 00:33:23.780 --> 00:33:29.130 align:middle line:90% 00:33:29.130 --> 00:33:41.730 align:middle line:84% Well, if we relax our conditions a little bit and we decide let's 00:33:41.730 --> 00:33:43.960 align:middle line:90% no longer require bipartite. 00:33:43.960 --> 00:33:46.650 align:middle line:84% Let's just let everyone rank everyone 00:33:46.650 --> 00:33:50.340 align:middle line:84% and then hope to find a stable matching 00:33:50.340 --> 00:33:54.450 align:middle line:90% in that non-bipartite graph. 00:33:54.450 --> 00:34:01.415 align:middle line:84% And here's an example of that, so non-bipartite example. 00:34:01.415 --> 00:34:07.620 align:middle line:90% 00:34:07.620 --> 00:34:09.305 align:middle line:84% And make sure I'm erasing well enough. 00:34:09.305 --> 00:34:14.400 align:middle line:90% 00:34:14.400 --> 00:34:19.409 align:middle line:84% All right, so let's imagine we have four people. 00:34:19.409 --> 00:34:24.719 align:middle line:84% They're going to be A, B, C, and D, and everyone's 00:34:24.719 --> 00:34:26.370 align:middle line:90% ranking everyone. 00:34:26.370 --> 00:34:29.639 align:middle line:84% So everyone has three other people to rank. 00:34:29.639 --> 00:34:37.440 align:middle line:84% And in this example, A prefers B, then prefers C, 00:34:37.440 --> 00:34:43.949 align:middle line:84% then prefers D. B prefers C, then prefers A, then 00:34:43.949 --> 00:34:47.290 align:middle line:90% prefers D. Let's see. 00:34:47.290 --> 00:34:54.300 align:middle line:84% So C prefers A, then B, then D. And I don't even 00:34:54.300 --> 00:34:57.540 align:middle line:90% care what D's preferences are. 00:34:57.540 --> 00:34:59.770 align:middle line:84% So let me write this out in the other way. 00:34:59.770 --> 00:35:05.910 align:middle line:84% So A prefers B, then C, then D. B prefers C, then A, then 00:35:05.910 --> 00:35:15.630 align:middle line:84% D. C prefers A, then B, then D. And D, I don't care. 00:35:15.630 --> 00:35:17.430 align:middle line:90% D can have any preference order. 00:35:17.430 --> 00:35:19.440 align:middle line:84% This example is already not going 00:35:19.440 --> 00:35:26.610 align:middle line:84% to have a stable matching because this graph is, 00:35:26.610 --> 00:35:28.000 align:middle line:90% in some sense, symmetric. 00:35:28.000 --> 00:35:30.580 align:middle line:84% So A, B, and C are all doing the same thing. 00:35:30.580 --> 00:35:34.240 align:middle line:84% They each prefer the next in order among A, B, and C, 00:35:34.240 --> 00:35:36.730 align:middle line:84% then the one after that, and then D is last. 00:35:36.730 --> 00:35:40.540 align:middle line:84% B prefers the next in order, then the one after that among A, 00:35:40.540 --> 00:35:43.420 align:middle line:90% B, and C, then D is last. 00:35:43.420 --> 00:35:46.180 align:middle line:84% C prefers the next in cyclic order, then the next, 00:35:46.180 --> 00:35:47.820 align:middle line:90% then D is last. 00:35:47.820 --> 00:35:51.240 align:middle line:84% So there are only three different matchings 00:35:51.240 --> 00:35:53.580 align:middle line:90% that we can make. 00:35:53.580 --> 00:35:55.920 align:middle line:84% D has to be matched with one of these three people, 00:35:55.920 --> 00:35:58.200 align:middle line:84% and then the other two are paired together. 00:35:58.200 --> 00:36:01.210 align:middle line:84% But since these three people are symmetric in this way, 00:36:01.210 --> 00:36:04.590 align:middle line:84% all three of those matchings, basically, behave the same way. 00:36:04.590 --> 00:36:09.240 align:middle line:84% So without loss of generality, we 00:36:09.240 --> 00:36:13.440 align:middle line:84% can assume that the matching looks like, let's say, A 00:36:13.440 --> 00:36:19.620 align:middle line:84% goes with D and B goes with C. The other two matchings are 00:36:19.620 --> 00:36:21.420 align:middle line:90% going to do something similar. 00:36:21.420 --> 00:36:23.223 align:middle line:90% Is this matching stable? 00:36:23.223 --> 00:36:31.800 align:middle line:90% 00:36:31.800 --> 00:36:35.890 align:middle line:84% And the answer if you look at it carefully, 00:36:35.890 --> 00:36:43.050 align:middle line:84% if you check all the pairs, the answer is that AC is rogue. 00:36:43.050 --> 00:36:47.700 align:middle line:84% According to that matching, AC is rogue. 00:36:47.700 --> 00:36:49.510 align:middle line:90% And let's check that. 00:36:49.510 --> 00:36:51.550 align:middle line:84% What does it mean for AC to be rogue? 00:36:51.550 --> 00:36:55.660 align:middle line:84% Well, it means A prefers C more than their assigned partner. 00:36:55.660 --> 00:36:58.800 align:middle line:84% So A is supposed to prefer C more than their assigned 00:36:58.800 --> 00:36:59.790 align:middle line:90% partner. 00:36:59.790 --> 00:37:04.180 align:middle line:84% And C is supposed to prefer A over their assigned partner 00:37:04.180 --> 00:37:05.460 align:middle line:90% which is B. 00:37:05.460 --> 00:37:09.210 align:middle line:90% So are these two things true? 00:37:09.210 --> 00:37:11.580 align:middle line:90% Well, does A prefer C over D? 00:37:11.580 --> 00:37:12.190 align:middle line:90% Well, yeah. 00:37:12.190 --> 00:37:14.760 align:middle line:84% A prefers everyone to D, so that's true. 00:37:14.760 --> 00:37:16.660 align:middle line:90% Does C prefer A over B? 00:37:16.660 --> 00:37:19.680 align:middle line:84% Well, yeah, that's the first thing we said. 00:37:19.680 --> 00:37:22.467 align:middle line:84% So A and C prefer each other more 00:37:22.467 --> 00:37:24.800 align:middle line:84% than their assigned partners, and are, therefore, rogue. 00:37:24.800 --> 00:37:27.420 align:middle line:90% 00:37:27.420 --> 00:37:30.133 align:middle line:90% So M is not stable. 00:37:30.133 --> 00:37:32.670 align:middle line:90% 00:37:32.670 --> 00:37:36.810 align:middle line:84% So this is an example where if you have a bipartite graph 00:37:36.810 --> 00:37:41.280 align:middle line:84% and preferences among everyone, then there won't always exist 00:37:41.280 --> 00:37:45.420 align:middle line:84% a stable matching, which is why it's so amazing that 00:37:45.420 --> 00:37:48.840 align:middle line:84% the Gale-Shapley algorithm which is looking only at bipartite 00:37:48.840 --> 00:37:51.630 align:middle line:84% graphs, it turns out-- and we're going to prove-- 00:37:51.630 --> 00:37:54.460 align:middle line:84% it always returns a stable matching. 00:37:54.460 --> 00:37:57.305 align:middle line:84% And in particular, there always exists a stable matching. 00:37:57.305 --> 00:38:11.430 align:middle line:90% 00:38:11.430 --> 00:38:19.733 align:middle line:84% So let's talk about the Gale-Shapley algorithm. 00:38:19.733 --> 00:38:21.150 align:middle line:84% This is, again, just for bipartite 00:38:21.150 --> 00:38:24.720 align:middle line:90% graphs as we set up over there. 00:38:24.720 --> 00:38:46.825 align:middle line:84% We're going to prove it always returns a stable matching, 00:38:46.825 --> 00:38:48.450 align:middle line:84% and, therefore, stable matchings always 00:38:48.450 --> 00:38:51.840 align:middle line:90% exist in bipartite graphs. 00:38:51.840 --> 00:38:56.100 align:middle line:84% Frequently, there will be many, many stable matchings 00:38:56.100 --> 00:38:58.620 align:middle line:90% for a given set of preferences. 00:38:58.620 --> 00:39:01.360 align:middle line:84% Gale-Shapley is only going to show us one of them. 00:39:01.360 --> 00:39:03.370 align:middle line:84% It's certainly going to find a stable matching, 00:39:03.370 --> 00:39:05.640 align:middle line:90% but not find all of them. 00:39:05.640 --> 00:39:06.490 align:middle line:90% All right. 00:39:06.490 --> 00:39:08.620 align:middle line:84% So let me describe this algorithm. 00:39:08.620 --> 00:39:09.926 align:middle line:90% So the algorithm. 00:39:09.926 --> 00:39:13.590 align:middle line:90% 00:39:13.590 --> 00:39:17.810 align:middle line:84% On each day, we do the following two steps. 00:39:17.810 --> 00:39:21.000 align:middle line:90% 00:39:21.000 --> 00:39:32.040 align:middle line:84% So step one, all applicants approach 00:39:32.040 --> 00:39:43.430 align:middle line:84% their favorite evaluator who hasn't yet rejected them. 00:39:43.430 --> 00:39:49.080 align:middle line:90% 00:39:49.080 --> 00:39:51.160 align:middle line:84% So all the applicants walk up and say, 00:39:51.160 --> 00:39:55.790 align:middle line:84% hey, I want to go to your hospital for my residency. 00:39:55.790 --> 00:40:01.360 align:middle line:84% And maybe Mass General gets seven applicants that morning. 00:40:01.360 --> 00:40:21.250 align:middle line:84% At step two, all evaluators reject all but their favorite 00:40:21.250 --> 00:40:23.320 align:middle line:90% that approached them that day. 00:40:23.320 --> 00:40:26.110 align:middle line:84% So seven people all approach MGH. 00:40:26.110 --> 00:40:27.940 align:middle line:84% MGH is going to look at all seven 00:40:27.940 --> 00:40:33.610 align:middle line:84% and say out of the seven of you, I prefer Dr. Evil. 00:40:33.610 --> 00:40:36.680 align:middle line:84% And the other six, you can leave forever. 00:40:36.680 --> 00:40:38.770 align:middle line:84% I never want to see your face again. 00:40:38.770 --> 00:40:42.460 align:middle line:84% Kind of harsh, but that's how the algorithm works. 00:40:42.460 --> 00:40:46.510 align:middle line:84% So you're going to do step one and step two every day, 00:40:46.510 --> 00:40:53.610 align:middle line:84% and stop when there are no more rejections. 00:40:53.610 --> 00:40:56.430 align:middle line:90% 00:40:56.430 --> 00:40:59.610 align:middle line:84% If a day ends and no one was rejected, 00:40:59.610 --> 00:41:02.160 align:middle line:84% then that's the end of the algorithm. 00:41:02.160 --> 00:41:03.995 align:middle line:90% Now, what I haven't said is-- 00:41:03.995 --> 00:41:06.120 align:middle line:84% so all applicants approach their favorite evaluator 00:41:06.120 --> 00:41:08.040 align:middle line:90% who hasn't yet rejected them-- 00:41:08.040 --> 00:41:11.370 align:middle line:84% if everyone has rejected them, then there's 00:41:11.370 --> 00:41:12.370 align:middle line:90% nothing for them to do. 00:41:12.370 --> 00:41:16.910 align:middle line:84% They go home and cry if possible. 00:41:16.910 --> 00:41:19.560 align:middle line:90% 00:41:19.560 --> 00:41:21.210 align:middle line:84% So if they get through their whole list 00:41:21.210 --> 00:41:23.340 align:middle line:84% and everyone has said no and they have no one else 00:41:23.340 --> 00:41:25.840 align:middle line:84% they can approach, there's nothing else for them to do. 00:41:25.840 --> 00:41:28.230 align:middle line:90% They just drop out. 00:41:28.230 --> 00:41:29.880 align:middle line:90% All right? 00:41:29.880 --> 00:41:30.973 align:middle line:90% Yes. 00:41:30.973 --> 00:41:32.640 align:middle line:84% AUDIENCE: For step two, are they allowed 00:41:32.640 --> 00:41:33.845 align:middle line:90% to have multiple favorites? 00:41:33.845 --> 00:41:37.680 align:middle line:84% Like if the favorite seems like the same for two 00:41:37.680 --> 00:41:39.523 align:middle line:84% different people, do they accept multiples? 00:41:39.523 --> 00:41:40.690 align:middle line:90% ZACHARY ABEL: Good question. 00:41:40.690 --> 00:41:43.620 align:middle line:84% So if an evaluator has two different favorites that 00:41:43.620 --> 00:41:47.490 align:middle line:84% are equally preferable, are they allowed to save both of them? 00:41:47.490 --> 00:41:48.520 align:middle line:90% So, no. 00:41:48.520 --> 00:41:52.270 align:middle line:84% Because of the way we set up the problem, there are no ties. 00:41:52.270 --> 00:41:55.080 align:middle line:84% They give a full strict ordering. 00:41:55.080 --> 00:41:59.290 align:middle line:84% So among any two people, they know which one they prefer. 00:41:59.290 --> 00:42:00.730 align:middle line:90% They have just a full list. 00:42:00.730 --> 00:42:03.060 align:middle line:84% So you'll never have ties for preferences. 00:42:03.060 --> 00:42:05.500 align:middle line:84% Out of however many applicants you get that day, 00:42:05.500 --> 00:42:07.210 align:middle line:84% there will be one clear favorite. 00:42:07.210 --> 00:42:09.630 align:middle line:84% And you temporarily hold on to them, 00:42:09.630 --> 00:42:11.260 align:middle line:90% and everyone else gets the boot. 00:42:11.260 --> 00:42:12.000 align:middle line:90% Yes. 00:42:12.000 --> 00:42:14.460 align:middle line:84% AUDIENCE: Does this only work for one-to-one ratios? 00:42:14.460 --> 00:42:15.050 align:middle line:90% ZACHARY ABEL: I'm sorry. 00:42:15.050 --> 00:42:16.883 align:middle line:84% AUDIENCE: Can you tell me if this only works 00:42:16.883 --> 00:42:18.120 align:middle line:90% for the one-to-one ratios? 00:42:18.120 --> 00:42:18.730 align:middle line:90% ZACHARY ABEL: Good question. 00:42:18.730 --> 00:42:20.770 align:middle line:84% Does this only work for one-to-one ratios? 00:42:20.770 --> 00:42:21.520 align:middle line:90% So, yes. 00:42:21.520 --> 00:42:23.700 align:middle line:84% Still, in this algorithm, we're only 00:42:23.700 --> 00:42:26.560 align:middle line:84% talking about n applicants and n evaluators. 00:42:26.560 --> 00:42:30.760 align:middle line:84% And each evaluator is going to end up with one applicant. 00:42:30.760 --> 00:42:34.350 align:middle line:84% And each applicant is going to end up with one evaluator. 00:42:34.350 --> 00:42:36.400 align:middle line:84% So we have the same number on each side 00:42:36.400 --> 00:42:38.285 align:middle line:84% and we're trying to find a perfect matching. 00:42:38.285 --> 00:42:40.200 align:middle line:90% Those are the rules of the game. 00:42:40.200 --> 00:42:41.820 align:middle line:90% Does that answer your question? 00:42:41.820 --> 00:42:43.980 align:middle line:90% Cool. 00:42:43.980 --> 00:42:48.840 align:middle line:84% It can be useful to see this algorithm running. 00:42:48.840 --> 00:42:50.440 align:middle line:90% It can be-- yes, awesome. 00:42:50.440 --> 00:42:54.130 align:middle line:90% So here's a 4x4 example. 00:42:54.130 --> 00:42:57.100 align:middle line:84% These preferences are just whatever preferences they have. 00:42:57.100 --> 00:42:59.080 align:middle line:84% We have the evaluators on the top. 00:42:59.080 --> 00:43:00.630 align:middle line:84% So imagine those are the med schools 00:43:00.630 --> 00:43:03.120 align:middle line:84% on the top and the doctors on the bottom that 00:43:03.120 --> 00:43:05.370 align:middle line:90% are doing the applications. 00:43:05.370 --> 00:43:09.840 align:middle line:84% So on day one, each of the applicants 00:43:09.840 --> 00:43:13.830 align:middle line:84% is going to approach the evaluator that they most prefer. 00:43:13.830 --> 00:43:15.670 align:middle line:84% Because there have been no rejections yet, 00:43:15.670 --> 00:43:18.390 align:middle line:84% so they all just go to their top choice. 00:43:18.390 --> 00:43:22.360 align:middle line:84% Evaluator 1 says, OK, well, A, you're my only applicant today, 00:43:22.360 --> 00:43:26.130 align:middle line:84% so I guess I'll hold on to you for now. 00:43:26.130 --> 00:43:31.590 align:middle line:84% Hospital 3 says, oh, no, I have three applicants Among those, I 00:43:31.590 --> 00:43:35.730 align:middle line:84% prefer D, so I'm going to reject B and C. 00:43:35.730 --> 00:43:37.870 align:middle line:90% So B and C are now gone forever. 00:43:37.870 --> 00:43:40.750 align:middle line:84% 3 will never talk to B and C again. 00:43:40.750 --> 00:43:42.670 align:middle line:84% And they get sent back down to the bottom. 00:43:42.670 --> 00:43:44.460 align:middle line:90% And that's day one. 00:43:44.460 --> 00:43:46.590 align:middle line:90% Did that make sense? 00:43:46.590 --> 00:43:47.440 align:middle line:90% Awesome. 00:43:47.440 --> 00:43:50.670 align:middle line:84% Now in day two, well, A and D still 00:43:50.670 --> 00:43:52.420 align:middle line:84% haven't been rejected by their top choice, 00:43:52.420 --> 00:43:54.990 align:middle line:84% so they're just going to stay there for the next day. 00:43:54.990 --> 00:43:58.420 align:middle line:84% But B and C who got rejected have to go find someone new. 00:43:58.420 --> 00:44:02.290 align:middle line:84% So they're going to go to the next one down their list. 00:44:02.290 --> 00:44:04.980 align:middle line:84% And it so happens that they're applying to the same place 00:44:04.980 --> 00:44:06.510 align:middle line:90% again this time. 00:44:06.510 --> 00:44:07.900 align:middle line:90% And now they're in conflict. 00:44:07.900 --> 00:44:12.750 align:middle line:84% So Hospital 2 says, I prefer B, so, C, get away from me. 00:44:12.750 --> 00:44:14.380 align:middle line:90% And that's the end of day two. 00:44:14.380 --> 00:44:16.420 align:middle line:90% Did that make sense? 00:44:16.420 --> 00:44:16.920 align:middle line:90% Nice. 00:44:16.920 --> 00:44:19.090 align:middle line:84% Who can tell me what's going to happen on day three? 00:44:19.090 --> 00:44:21.780 align:middle line:84% At least the first step of day three. 00:44:21.780 --> 00:44:23.020 align:middle line:90% Yep, up there. 00:44:23.020 --> 00:44:24.450 align:middle line:90% AUDIENCE: C is going to go to 1. 00:44:24.450 --> 00:44:27.370 align:middle line:84% ZACHARY ABEL: Yeah, C looks through their list and says, OK. 00:44:27.370 --> 00:44:30.670 align:middle line:84% Evaluator 1 is my next favorite that hasn't rejected me, 00:44:30.670 --> 00:44:33.300 align:middle line:84% so I'm going to go over here to 1. 00:44:33.300 --> 00:44:34.350 align:middle line:90% All right? 00:44:34.350 --> 00:44:37.830 align:middle line:84% And now Evaluator 1 says, oh, there's a contest. 00:44:37.830 --> 00:44:41.140 align:middle line:84% Between A and C, looks like I prefer C this time. 00:44:41.140 --> 00:44:42.790 align:middle line:90% So now A goes away. 00:44:42.790 --> 00:44:45.730 align:middle line:84% So even though A had been held on for a couple days, 00:44:45.730 --> 00:44:49.540 align:middle line:84% someone better came along, so A gets kicked out. 00:44:49.540 --> 00:44:52.530 align:middle line:90% It's a cutthroat game. 00:44:52.530 --> 00:44:53.830 align:middle line:90% And let's keep going. 00:44:53.830 --> 00:44:57.120 align:middle line:84% Next day, A says, OK, well my next favorite 00:44:57.120 --> 00:44:59.670 align:middle line:90% is 3, next down my list. 00:44:59.670 --> 00:45:02.590 align:middle line:84% And I want to emphasize it's now day four, 00:45:02.590 --> 00:45:05.790 align:middle line:84% but we're not looking at A's fourth choice. 00:45:05.790 --> 00:45:07.560 align:middle line:84% We're only looking at A's second choice 00:45:07.560 --> 00:45:09.910 align:middle line:84% because A has only been rejected once so far. 00:45:09.910 --> 00:45:11.790 align:middle line:84% So we're always going to the next choice 00:45:11.790 --> 00:45:14.760 align:middle line:84% for that person, which might be at a different place 00:45:14.760 --> 00:45:16.860 align:middle line:90% for each person on that day. 00:45:16.860 --> 00:45:19.720 align:middle line:90% So A goes to a Hospital 3. 00:45:19.720 --> 00:45:24.300 align:middle line:84% Hospital 3 says, nuh-uh, and sends A away again. 00:45:24.300 --> 00:45:26.650 align:middle line:90% Now A goes to hospital 2. 00:45:26.650 --> 00:45:30.370 align:middle line:84% Hospital 2 says, oh yeah, OK, I like that one, so B can go away. 00:45:30.370 --> 00:45:33.700 align:middle line:84% And now B has to go fend for themselves somewhere else. 00:45:33.700 --> 00:45:38.080 align:middle line:84% So B goes to Hospital 1 and gets rejected. 00:45:38.080 --> 00:45:39.580 align:middle line:90% B goes to Hospital 4. 00:45:39.580 --> 00:45:43.450 align:middle line:84% And finally, there's nothing else to do. 00:45:43.450 --> 00:45:46.860 align:middle line:84% No one is rejected, so the algorithm is done. 00:45:46.860 --> 00:45:49.230 align:middle line:90% Did that make sense? 00:45:49.230 --> 00:45:51.330 align:middle line:90% Wonderful. 00:45:51.330 --> 00:45:54.960 align:middle line:84% Let's make it make even more sense by doing an algorithm 00:45:54.960 --> 00:45:56.820 align:middle line:90% ourselves by hand. 00:45:56.820 --> 00:45:58.390 align:middle line:90% So we've seen it run once. 00:45:58.390 --> 00:45:59.963 align:middle line:90% Now let's run it ourselves once. 00:45:59.963 --> 00:46:09.180 align:middle line:90% 00:46:09.180 --> 00:46:11.320 align:middle line:90% So let's do this algorithm. 00:46:11.320 --> 00:46:13.050 align:middle line:90% So on day one-- 00:46:13.050 --> 00:46:15.090 align:middle line:90% so let's see. 00:46:15.090 --> 00:46:17.553 align:middle line:84% Let me make sure I'm matching my notes. 00:46:17.553 --> 00:46:21.840 align:middle line:90% 00:46:21.840 --> 00:46:27.510 align:middle line:84% Yeah, so I want these on the left to be the evaluators, 00:46:27.510 --> 00:46:31.200 align:middle line:84% and these on the right to be the applicants. 00:46:31.200 --> 00:46:33.390 align:middle line:84% So every day, F through J are going 00:46:33.390 --> 00:46:35.560 align:middle line:84% to apply to their best remaining choice. 00:46:35.560 --> 00:46:38.730 align:middle line:84% And A through E are going to make decisions. 00:46:38.730 --> 00:46:45.720 align:middle line:84% So A, B, C, D, E. What happens on day one? 00:46:45.720 --> 00:46:48.480 align:middle line:90% 00:46:48.480 --> 00:46:51.580 align:middle line:84% F through J are each going to apply to their top choice, OK? 00:46:51.580 --> 00:47:00.240 align:middle line:84% So F applies to C, G to A, H to D, I to A, and J to A. OK. 00:47:00.240 --> 00:47:09.165 align:middle line:84% So F goes to C, G goes to A, H goes to D, I goes to A, 00:47:09.165 --> 00:47:11.340 align:middle line:90% and J goes to A. 00:47:11.340 --> 00:47:15.210 align:middle line:84% So these are the applications on day one. 00:47:15.210 --> 00:47:20.190 align:middle line:84% And then Evaluator A says between G, I, and J-- 00:47:20.190 --> 00:47:30.360 align:middle line:84% between G I and J, I prefer J. So G and I are rejected. 00:47:30.360 --> 00:47:33.150 align:middle line:90% G and I are rejected. 00:47:33.150 --> 00:47:35.700 align:middle line:90% G and I are rejected. 00:47:35.700 --> 00:47:38.070 align:middle line:90% Sound good? 00:47:38.070 --> 00:47:39.310 align:middle line:90% I see some head shake. 00:47:39.310 --> 00:47:44.340 align:middle line:84% Was that a question or is it just funny that we're being 00:47:44.340 --> 00:47:45.930 align:middle line:90% so aggressive? 00:47:45.930 --> 00:47:46.730 align:middle line:90% Wonderful. 00:47:46.730 --> 00:47:47.230 align:middle line:90% All right. 00:47:47.230 --> 00:47:48.647 align:middle line:84% So that's what happens on day one. 00:47:48.647 --> 00:47:51.690 align:middle line:90% What about day two? 00:47:51.690 --> 00:47:54.330 align:middle line:84% Well, J, F, and H weren't rejected, 00:47:54.330 --> 00:47:56.130 align:middle line:90% so they stay where they are. 00:47:56.130 --> 00:47:57.720 align:middle line:90% So J stays here. 00:47:57.720 --> 00:47:58.590 align:middle line:90% F stays here. 00:47:58.590 --> 00:48:00.010 align:middle line:90% H stays here. 00:48:00.010 --> 00:48:02.530 align:middle line:84% But G and I have to go somewhere new. 00:48:02.530 --> 00:48:13.390 align:middle line:84% So G is now going over to B. And I is going over to C. All right. 00:48:13.390 --> 00:48:15.070 align:middle line:90% And now C has a choice. 00:48:15.070 --> 00:48:17.700 align:middle line:90% C can choose between F and I. 00:48:17.700 --> 00:48:21.960 align:middle line:84% C can choose between F and I. Oh, C 00:48:21.960 --> 00:48:27.180 align:middle line:84% is definitely choosing I. F is way down at the bottom. 00:48:27.180 --> 00:48:31.500 align:middle line:90% So F is sad. 00:48:31.500 --> 00:48:33.640 align:middle line:84% And I believe that's the end of day two. 00:48:33.640 --> 00:48:34.900 align:middle line:90% Stop me if I make a mistake. 00:48:34.900 --> 00:48:37.620 align:middle line:84% I very well might make a mistake here. 00:48:37.620 --> 00:48:39.360 align:middle line:90% Day three. 00:48:39.360 --> 00:48:41.328 align:middle line:84% Well, the only one that got rejected was F. 00:48:41.328 --> 00:48:43.620 align:middle line:84% So they're the only one that needs to go somewhere new. 00:48:43.620 --> 00:48:47.820 align:middle line:84% So we can just copy over J, G, I, H. 00:48:47.820 --> 00:48:50.220 align:middle line:90% And F, where is F going? 00:48:50.220 --> 00:48:51.990 align:middle line:84% F was rejected from C, so they're 00:48:51.990 --> 00:48:59.070 align:middle line:84% going to B. Let's hope F has a better day today than yesterday. 00:48:59.070 --> 00:49:04.110 align:middle line:84% So B is now choosing between G and F. And looks like F 00:49:04.110 --> 00:49:07.920 align:middle line:84% wins this time, so G is rejected. 00:49:07.920 --> 00:49:09.300 align:middle line:90% Whew, OK. 00:49:09.300 --> 00:49:15.360 align:middle line:84% So G was rejected from B. And tomorrow needs to go to E. 00:49:15.360 --> 00:49:19.350 align:middle line:84% So day four, G is going down here to E. H, 00:49:19.350 --> 00:49:21.780 align:middle line:84% I, F, and J were not rejected, so they 00:49:21.780 --> 00:49:23.910 align:middle line:90% stay put for the next day. 00:49:23.910 --> 00:49:29.130 align:middle line:84% And finally, there's no contest, so there's no rejection. 00:49:29.130 --> 00:49:30.525 align:middle line:84% And finally, we have a matching-- 00:49:30.525 --> 00:49:36.120 align:middle line:84% A with J, B with F, C with I, D with H, and E with G. 00:49:36.120 --> 00:49:38.340 align:middle line:90% Did that make sense? 00:49:38.340 --> 00:49:39.660 align:middle line:90% Question? 00:49:39.660 --> 00:49:42.970 align:middle line:84% AUDIENCE: If you flip the evaluators and the applicants, 00:49:42.970 --> 00:49:44.310 align:middle line:90% do you get the same matching? 00:49:44.310 --> 00:49:45.685 align:middle line:84% ZACHARY ABEL: Excellent question. 00:49:45.685 --> 00:49:47.740 align:middle line:84% If we flip the evaluators and the applicants, 00:49:47.740 --> 00:49:50.910 align:middle line:90% do we get the same matching? 00:49:50.910 --> 00:49:53.533 align:middle line:84% So as we said earlier, the relationship 00:49:53.533 --> 00:49:54.700 align:middle line:90% is kind of symmetric, right? 00:49:54.700 --> 00:49:56.560 align:middle line:84% They're all giving equivalent data. 00:49:56.560 --> 00:49:59.250 align:middle line:84% We could have run this in the opposite direction 00:49:59.250 --> 00:50:02.850 align:middle line:84% where F through J are the evaluators and A through E 00:50:02.850 --> 00:50:04.270 align:middle line:90% are the applicants. 00:50:04.270 --> 00:50:06.960 align:middle line:84% And I have claimed so far that we're 00:50:06.960 --> 00:50:09.660 align:middle line:84% going to end up with a perfect matching. 00:50:09.660 --> 00:50:11.550 align:middle line:84% Turns out, usually what you're going to get 00:50:11.550 --> 00:50:14.160 align:middle line:90% is a different perfect matching. 00:50:14.160 --> 00:50:16.470 align:middle line:84% And we're going to say very precisely why that 00:50:16.470 --> 00:50:19.020 align:middle line:90% is a little later on. 00:50:19.020 --> 00:50:20.110 align:middle line:90% So a really good question. 00:50:20.110 --> 00:50:22.360 align:middle line:84% But yeah, just always keep that in the back of your mind. 00:50:22.360 --> 00:50:24.510 align:middle line:84% You could have run the algorithm in the opposite direction 00:50:24.510 --> 00:50:25.740 align:middle line:84% and you'll probably end up getting 00:50:25.740 --> 00:50:26.907 align:middle line:90% a different stable matching. 00:50:26.907 --> 00:50:27.780 align:middle line:90% Yes. 00:50:27.780 --> 00:50:29.640 align:middle line:84% AUDIENCE: Similarly, does the order matter? 00:50:29.640 --> 00:50:31.380 align:middle line:84% Because of the way you assigned them 00:50:31.380 --> 00:50:35.017 align:middle line:84% the first day kind of goes based on the ordering [INAUDIBLE]. 00:50:35.017 --> 00:50:36.850 align:middle line:84% ZACHARY ABEL: Does the order of what matter? 00:50:36.850 --> 00:50:37.892 align:middle line:90% AUDIENCE: The applicants. 00:50:37.892 --> 00:50:39.750 align:middle line:84% ZACHARY ABEL: The order of the applicants. 00:50:39.750 --> 00:50:41.985 align:middle line:84% So the order of the applicants doesn't matter. 00:50:41.985 --> 00:50:43.860 align:middle line:84% The only thing that matters for the algorithm 00:50:43.860 --> 00:50:46.450 align:middle line:84% is the individual rankings for each person. 00:50:46.450 --> 00:50:51.180 align:middle line:84% But the fact that like G, I, and J approached A in that order 00:50:51.180 --> 00:50:53.110 align:middle line:90% on day one didn't matter. 00:50:53.110 --> 00:50:55.290 align:middle line:84% All that matters is that these three approached, 00:50:55.290 --> 00:50:58.210 align:middle line:84% and J is the best out of these three. 00:50:58.210 --> 00:50:58.710 align:middle line:90% Cool. 00:50:58.710 --> 00:51:00.960 align:middle line:90% Good question. 00:51:00.960 --> 00:51:02.460 align:middle line:90% All right. 00:51:02.460 --> 00:51:06.160 align:middle line:84% So we got a matching out of this example. 00:51:06.160 --> 00:51:08.310 align:middle line:90% Is it a stable matching? 00:51:08.310 --> 00:51:12.270 align:middle line:84% If my theorem is to be believed, or if Gale and Shapley's theorem 00:51:12.270 --> 00:51:14.100 align:middle line:84% is to be believed, then, yes, this 00:51:14.100 --> 00:51:15.280 align:middle line:90% should be a stable matching. 00:51:15.280 --> 00:51:18.640 align:middle line:84% And in this case, if you check all the possible rogue pairs, 00:51:18.640 --> 00:51:21.610 align:middle line:84% turns out, yes, this is stable for this example. 00:51:21.610 --> 00:51:24.930 align:middle line:84% So that's at least one point in favor of this algorithm 00:51:24.930 --> 00:51:26.410 align:middle line:90% producing correct results. 00:51:26.410 --> 00:51:27.327 align:middle line:90% Question? 00:51:27.327 --> 00:51:29.910 align:middle line:84% AUDIENCE: If you were to weight these as like the first choice 00:51:29.910 --> 00:51:32.040 align:middle line:84% as one, second choice as two, third-- 00:51:32.040 --> 00:51:36.500 align:middle line:84% is this necessarily like the smallest weight as well, 00:51:36.500 --> 00:51:37.080 align:middle line:90% or is it-- 00:51:37.080 --> 00:51:39.300 align:middle line:84% ZACHARY ABEL: Interesting question. 00:51:39.300 --> 00:51:42.420 align:middle line:84% If we give a weight for who gets which preference-- 00:51:42.420 --> 00:51:47.540 align:middle line:84% so first choice gets one point, second choice gets two points, 00:51:47.540 --> 00:51:50.000 align:middle line:90% and all the way down-- 00:51:50.000 --> 00:51:51.680 align:middle line:84% does this algorithm give a matching 00:51:51.680 --> 00:51:54.260 align:middle line:90% with lowest total weight? 00:51:54.260 --> 00:51:55.600 align:middle line:90% That's a really great question. 00:51:55.600 --> 00:51:58.490 align:middle line:90% 00:51:58.490 --> 00:52:00.960 align:middle line:84% At least if you're counting it on one side, 00:52:00.960 --> 00:52:02.490 align:middle line:84% I'm pretty sure the answer is yes. 00:52:02.490 --> 00:52:04.157 align:middle line:84% If you're counting it on the other side, 00:52:04.157 --> 00:52:06.680 align:middle line:84% I'm pretty sure it gives a matching 00:52:06.680 --> 00:52:10.910 align:middle line:84% with the maximum total weight, which is probably not the side 00:52:10.910 --> 00:52:11.520 align:middle line:90% that you want. 00:52:11.520 --> 00:52:13.700 align:middle line:90% You want lower ranks. 00:52:13.700 --> 00:52:15.210 align:middle line:84% But, yeah, really great question. 00:52:15.210 --> 00:52:18.110 align:middle line:84% So there are lots of ways you can see this as, in some sense, 00:52:18.110 --> 00:52:19.650 align:middle line:90% some optimization problem. 00:52:19.650 --> 00:52:21.890 align:middle line:84% We want to maximize happiness, which 00:52:21.890 --> 00:52:26.210 align:middle line:84% means minimizing how far along your ranking list 00:52:26.210 --> 00:52:29.280 align:middle line:84% you have to go before you find a match. 00:52:29.280 --> 00:52:29.780 align:middle line:90% Cool. 00:52:29.780 --> 00:52:35.840 align:middle line:84% So let's try to prove why this algorithm does, in fact, give us 00:52:35.840 --> 00:52:36.742 align:middle line:90% stable matchings. 00:52:36.742 --> 00:52:38.700 align:middle line:84% And there are a couple of things to prove here. 00:52:38.700 --> 00:52:38.900 align:middle line:90% Let's see. 00:52:38.900 --> 00:52:39.817 align:middle line:90% Where did I leave off? 00:52:39.817 --> 00:52:45.543 align:middle line:90% 00:52:45.543 --> 00:52:46.043 align:middle line:90% OK. 00:52:46.043 --> 00:52:49.907 align:middle line:90% 00:52:49.907 --> 00:52:52.786 align:middle line:84% So first question, so we've given an algorithm. 00:52:52.786 --> 00:52:56.600 align:middle line:90% 00:52:56.600 --> 00:52:59.210 align:middle line:84% In this class, usually, when we're talking about algorithms, 00:52:59.210 --> 00:53:02.300 align:middle line:84% we're talking about state machines. 00:53:02.300 --> 00:53:16.460 align:middle line:84% And so we can think of this algorithm as a state machine 00:53:16.460 --> 00:53:21.950 align:middle line:84% where each state is the set of rejections 00:53:21.950 --> 00:53:23.125 align:middle line:90% that have happened so far. 00:53:23.125 --> 00:53:38.810 align:middle line:90% 00:53:38.810 --> 00:53:40.860 align:middle line:84% So to know where you are in the algorithm 00:53:40.860 --> 00:53:43.290 align:middle line:84% and where you have to resume to start the next day, 00:53:43.290 --> 00:53:46.160 align:middle line:84% all you need to know is which things have been crossed off 00:53:46.160 --> 00:53:48.270 align:middle line:90% from which people's lists. 00:53:48.270 --> 00:53:49.863 align:middle line:84% And then what happens the next day, 00:53:49.863 --> 00:53:51.530 align:middle line:84% because each of the applicants just goes 00:53:51.530 --> 00:53:53.870 align:middle line:90% to the next one in their list. 00:53:53.870 --> 00:53:54.840 align:middle line:90% All right? 00:53:54.840 --> 00:54:05.660 align:middle line:84% And transitions correspond to run one day of the algorithm. 00:54:05.660 --> 00:54:08.840 align:middle line:84% This is a way to translate to transform one set of rejections 00:54:08.840 --> 00:54:11.880 align:middle line:84% into probably a slightly bigger set of rejections. 00:54:11.880 --> 00:54:14.840 align:middle line:84% Whatever rejections happen on that day are now also 00:54:14.840 --> 00:54:17.840 align:middle line:90% part of the new state. 00:54:17.840 --> 00:54:19.760 align:middle line:84% And now we can ask state machine questions 00:54:19.760 --> 00:54:29.960 align:middle line:84% like does the Gale-Shapley state machine terminate or might it 00:54:29.960 --> 00:54:32.690 align:middle line:90% run forever? 00:54:32.690 --> 00:54:33.625 align:middle line:90% Who can tell me? 00:54:33.625 --> 00:54:39.890 align:middle line:90% 00:54:39.890 --> 00:54:40.550 align:middle line:90% Yes. 00:54:40.550 --> 00:54:41.150 align:middle line:90% AUDIENCE: It terminates. 00:54:41.150 --> 00:54:42.317 align:middle line:90% ZACHARY ABEL: It terminates. 00:54:42.317 --> 00:54:42.950 align:middle line:90% Why? 00:54:42.950 --> 00:54:44.360 align:middle line:84% AUDIENCE: It says so in the lecture notes. 00:54:44.360 --> 00:54:46.080 align:middle line:84% ZACHARY ABEL: It says so in the lecture notes. 00:54:46.080 --> 00:54:47.153 align:middle line:90% Ooh, appeal to authority. 00:54:47.153 --> 00:54:49.700 align:middle line:90% [LAUGHTER] 00:54:49.700 --> 00:54:52.440 align:middle line:84% I say it terminates, and therefore, it terminates. 00:54:52.440 --> 00:54:54.290 align:middle line:90% Ooh! 00:54:54.290 --> 00:54:57.510 align:middle line:84% Unfortunately, I can't use that justification for myself 00:54:57.510 --> 00:55:00.630 align:middle line:84% because if I wrote the lecture notes, then I am that authority. 00:55:00.630 --> 00:55:03.300 align:middle line:84% So that's not a valid proof for me to use. 00:55:03.300 --> 00:55:05.900 align:middle line:84% So I would ask that you not use it either. 00:55:05.900 --> 00:55:07.175 align:middle line:90% Yes, down here. 00:55:07.175 --> 00:55:09.800 align:middle line:84% AUDIENCE: I mean, there are only a limited number of rejections 00:55:09.800 --> 00:55:11.553 align:middle line:84% that can happen and then they run out. 00:55:11.553 --> 00:55:12.470 align:middle line:90% ZACHARY ABEL: Awesome. 00:55:12.470 --> 00:55:15.180 align:middle line:84% There are only a limited number of rejections that can happen. 00:55:15.180 --> 00:55:15.980 align:middle line:90% Exactly. 00:55:15.980 --> 00:55:18.930 align:middle line:84% So every day that the algorithm continues, 00:55:18.930 --> 00:55:21.120 align:middle line:90% at least one rejection happens. 00:55:21.120 --> 00:55:24.560 align:middle line:84% But there are only n squared rejections 00:55:24.560 --> 00:55:26.771 align:middle line:90% that can happen in total. 00:55:26.771 --> 00:55:28.926 align:middle line:90% Right. 00:55:28.926 --> 00:55:38.510 align:middle line:84% So there are, at most, n squared rejections possible. 00:55:38.510 --> 00:55:43.016 align:middle line:84% We use at least one for every transition. 00:55:43.016 --> 00:55:46.820 align:middle line:90% 00:55:46.820 --> 00:55:55.850 align:middle line:84% So we can follow, at most, n squared transitions 00:55:55.850 --> 00:55:57.270 align:middle line:90% before terminating. 00:55:57.270 --> 00:56:01.850 align:middle line:90% 00:56:01.850 --> 00:56:04.730 align:middle line:84% Yeah, we terminate just because we constantly 00:56:04.730 --> 00:56:06.720 align:middle line:90% use up a limited resource. 00:56:06.720 --> 00:56:10.550 align:middle line:84% And we have to finish at some point before we eat up 00:56:10.550 --> 00:56:14.030 align:middle line:84% that resource, or in the worst case, when we finish going 00:56:14.030 --> 00:56:15.450 align:middle line:90% through all of that resource. 00:56:15.450 --> 00:56:18.420 align:middle line:84% So worst case, everyone gets rejected from everywhere 00:56:18.420 --> 00:56:20.390 align:middle line:90% and then we stop. 00:56:20.390 --> 00:56:21.380 align:middle line:90% Yes. 00:56:21.380 --> 00:56:23.080 align:middle line:84% AUDIENCE: Is n the number of applicants? 00:56:23.080 --> 00:56:25.080 align:middle line:84% ZACHARY ABEL: Yes, n is the number of applicants 00:56:25.080 --> 00:56:26.606 align:middle line:90% and the number of evaluators. 00:56:26.606 --> 00:56:27.898 align:middle line:90% AUDIENCE: Oh, they're the same. 00:56:27.898 --> 00:56:30.330 align:middle line:84% ZACHARY ABEL: They're the same, yes. 00:56:30.330 --> 00:56:31.900 align:middle line:90% All right, so it terminates. 00:56:31.900 --> 00:56:32.400 align:middle line:90% Yes. 00:56:32.400 --> 00:56:33.390 align:middle line:90% Awesome. 00:56:33.390 --> 00:56:36.300 align:middle line:90% Next important question. 00:56:36.300 --> 00:56:41.227 align:middle line:84% When it terminates, does everyone have a partner? 00:56:41.227 --> 00:56:42.810 align:middle line:84% We were saying earlier that if someone 00:56:42.810 --> 00:56:45.340 align:middle line:84% gets rejected from everyone, they go home crying. 00:56:45.340 --> 00:56:47.230 align:middle line:90% So does anyone go home crying? 00:56:47.230 --> 00:56:48.970 align:middle line:90% We'd like that answer to be no. 00:56:48.970 --> 00:56:52.565 align:middle line:84% We'd like everyone to have a partner at the end. 00:56:52.565 --> 00:56:59.190 align:middle line:90% 00:56:59.190 --> 00:56:59.930 align:middle line:90% All right. 00:56:59.930 --> 00:57:11.370 align:middle line:90% 00:57:11.370 --> 00:57:14.790 align:middle line:84% In the examples we've seen on the projector 00:57:14.790 --> 00:57:17.550 align:middle line:84% and on the board over there, we did end 00:57:17.550 --> 00:57:20.070 align:middle line:90% with an actual perfect matching. 00:57:20.070 --> 00:57:21.970 align:middle line:84% No one got rejected from everywhere. 00:57:21.970 --> 00:57:24.770 align:middle line:90% So is that true in general? 00:57:24.770 --> 00:57:27.920 align:middle line:84% And to talk about this, and also to understand the algorithm 00:57:27.920 --> 00:57:33.530 align:middle line:84% a little better in general, let me give us some invariants 00:57:33.530 --> 00:57:35.130 align:middle line:90% of this algorithm. 00:57:35.130 --> 00:57:36.750 align:middle line:84% This algorithm is a state machine, 00:57:36.750 --> 00:57:38.360 align:middle line:84% so let's use invariants and preserve 00:57:38.360 --> 00:57:40.200 align:middle line:90% properties to talk about it. 00:57:40.200 --> 00:57:43.106 align:middle line:90% So let's see-- invariant. 00:57:43.106 --> 00:57:47.810 align:middle line:90% 00:57:47.810 --> 00:58:03.650 align:middle line:84% Each applicant has been rejected from a prefix 00:58:03.650 --> 00:58:05.575 align:middle line:90% of their preference list. 00:58:05.575 --> 00:58:10.310 align:middle line:90% 00:58:10.310 --> 00:58:14.960 align:middle line:84% So on any particular day, if you look at one of these blue guys 00:58:14.960 --> 00:58:17.490 align:middle line:84% and ask who they've been rejected from, 00:58:17.490 --> 00:58:20.820 align:middle line:84% it's always from the top of their list down to some point. 00:58:20.820 --> 00:58:23.310 align:middle line:84% And that's just because of how the algorithm runs. 00:58:23.310 --> 00:58:26.030 align:middle line:84% Every day, an applicant goes to the top choice that 00:58:26.030 --> 00:58:30.020 align:middle line:84% hasn't rejected them yet, and either they stay with them 00:58:30.020 --> 00:58:33.530 align:middle line:84% for another day, or that evaluator rejects them 00:58:33.530 --> 00:58:35.450 align:middle line:90% and the prefix gets one longer. 00:58:35.450 --> 00:58:39.860 align:middle line:84% But either way, they're always rejected from a prefix, 00:58:39.860 --> 00:58:59.720 align:middle line:84% in particular, each applicant approaches worse evaluators 00:58:59.720 --> 00:59:09.470 align:middle line:84% over time since applicants always go down their list 00:59:09.470 --> 00:59:12.140 align:middle line:90% from the top. 00:59:12.140 --> 00:59:16.490 align:middle line:84% They're always approaching their favorite evaluators every time 00:59:16.490 --> 00:59:17.580 align:middle line:90% they can. 00:59:17.580 --> 00:59:19.510 align:middle line:84% And if they're ever rejected, they 00:59:19.510 --> 00:59:20.700 align:middle line:90% have to go to someone worse. 00:59:20.700 --> 00:59:22.117 align:middle line:84% And if they're rejected, they have 00:59:22.117 --> 00:59:23.660 align:middle line:90% to go to someone worse again. 00:59:23.660 --> 00:59:26.810 align:middle line:84% So the evaluators that they're approaching only ever 00:59:26.810 --> 00:59:29.285 align:middle line:84% get worse over time or stay constant 00:59:29.285 --> 00:59:30.660 align:middle line:84% if they're not rejected that day. 00:59:30.660 --> 00:59:32.300 align:middle line:90% But they never get better. 00:59:32.300 --> 00:59:37.220 align:middle line:84% So applicants' prospects only ever get worse. 00:59:37.220 --> 00:59:41.600 align:middle line:84% And the opposite happens for the evaluators. 00:59:41.600 --> 00:59:54.060 align:middle line:90% I claim that each evaluator-- 00:59:54.060 --> 00:59:56.110 align:middle line:90% ooh, I can't spell evaluators-- 00:59:56.110 --> 00:59:59.990 align:middle line:90% 00:59:59.990 --> 01:00:08.350 align:middle line:84% picks from day to day only get better. 01:00:08.350 --> 01:00:13.580 align:middle line:90% 01:00:13.580 --> 01:00:17.810 align:middle line:84% And if you think about this from the perspective of an evaluator, 01:00:17.810 --> 01:00:19.785 align:middle line:84% well, if no one has ever approached them, 01:00:19.785 --> 01:00:21.660 align:middle line:84% then there's nothing for them to do that day. 01:00:21.660 --> 01:00:23.077 align:middle line:84% But if someone has approached them 01:00:23.077 --> 01:00:26.370 align:middle line:84% and they have some number of people in front of them, 01:00:26.370 --> 01:00:29.280 align:middle line:84% they're always going to pick the best from whoever's there. 01:00:29.280 --> 01:00:32.240 align:middle line:84% When the next day happens, they at least 01:00:32.240 --> 01:00:35.460 align:middle line:84% have that same person again and possibly others. 01:00:35.460 --> 01:00:37.580 align:middle line:84% And if there's someone better, then they'll 01:00:37.580 --> 01:00:39.390 align:middle line:84% trade up and take someone better. 01:00:39.390 --> 01:00:41.300 align:middle line:90% But they never trade down. 01:00:41.300 --> 01:00:45.650 align:middle line:84% The evaluators always only keep who they had yesterday 01:00:45.650 --> 01:00:48.770 align:middle line:84% or trade up to someone better for the next day. 01:00:48.770 --> 01:00:52.970 align:middle line:84% So evaluators' prospects only get better and better from day 01:00:52.970 --> 01:00:54.110 align:middle line:90% to day. 01:00:54.110 --> 01:00:57.260 align:middle line:84% We can be a little more precise about this. 01:00:57.260 --> 01:00:57.900 align:middle line:90% Let's see. 01:00:57.900 --> 01:00:58.966 align:middle line:90% So invariant. 01:00:58.966 --> 01:01:02.180 align:middle line:90% 01:01:02.180 --> 01:01:11.090 align:middle line:84% So for all applicants and for all evaluators, 01:01:11.090 --> 01:01:21.020 align:middle line:84% if the evaluator has ever rejected that applicant, 01:01:21.020 --> 01:01:27.120 align:middle line:84% then the evaluator has a favorite-- 01:01:27.120 --> 01:01:33.230 align:middle line:84% I'm going to call them a candidate-- has a candidate 01:01:33.230 --> 01:01:38.570 align:middle line:90% better than A. 01:01:38.570 --> 01:01:43.400 align:middle line:84% So if Dr. Jekyll approaches Brigham and Women's and is 01:01:43.400 --> 01:01:47.870 align:middle line:84% rejected on day 12, then for all future days, Brigham 01:01:47.870 --> 01:01:50.150 align:middle line:84% and Women's is going to have some candidate 01:01:50.150 --> 01:01:54.590 align:middle line:84% that they finish the day with that's better than Dr. Jekyll. 01:01:54.590 --> 01:01:57.450 align:middle line:84% And that's just a more precise way of saying this. 01:01:57.450 --> 01:02:01.820 align:middle line:84% Every day they either keep who they had yesterday or trade 01:02:01.820 --> 01:02:04.010 align:middle line:90% up to someone strictly better. 01:02:04.010 --> 01:02:07.790 align:middle line:84% So when they rejected Dr. Jekyll, 01:02:07.790 --> 01:02:10.710 align:middle line:84% they finished that day with someone better than Dr. Jekyll 01:02:10.710 --> 01:02:15.590 align:middle line:84% because that's the only reason you would reject Dr. Jekyll. 01:02:15.590 --> 01:02:18.960 align:middle line:84% And then from then on, they either keep or trade up. 01:02:18.960 --> 01:02:20.870 align:middle line:90% They only ever get better. 01:02:20.870 --> 01:02:24.260 align:middle line:90% Does this invariant make sense? 01:02:24.260 --> 01:02:25.040 align:middle line:90% Awesome. 01:02:25.040 --> 01:02:28.230 align:middle line:84% So if evaluator has rejected applicant, 01:02:28.230 --> 01:02:30.320 align:middle line:84% then evaluator is always going to have a candidate 01:02:30.320 --> 01:02:33.050 align:middle line:84% better than that applicant from then on. 01:02:33.050 --> 01:02:35.460 align:middle line:84% So now, let's answer this question. 01:02:35.460 --> 01:02:38.420 align:middle line:84% Does everyone have a partner at the end? 01:02:38.420 --> 01:02:41.320 align:middle line:84% And let's see what happens if they don't. 01:02:41.320 --> 01:02:55.730 align:middle line:90% 01:02:55.730 --> 01:02:58.310 align:middle line:84% So by way of contradiction, let's 01:02:58.310 --> 01:03:02.480 align:middle line:84% pick one particular applicant, say, Dr. Jekyll. 01:03:02.480 --> 01:03:09.740 align:middle line:84% So by way of contradiction, assume Dr. Jekyll 01:03:09.740 --> 01:03:15.870 align:middle line:90% was rejected by everyone-- 01:03:15.870 --> 01:03:19.430 align:middle line:90% 01:03:19.430 --> 01:03:22.730 align:middle line:84% was rejected by all of the evaluators. 01:03:22.730 --> 01:03:23.340 align:middle line:90% All right? 01:03:23.340 --> 01:03:25.190 align:middle line:84% And let's see what goes wrong here. 01:03:25.190 --> 01:03:27.126 align:middle line:84% Well, at the end of the algorithm-- 01:03:27.126 --> 01:03:30.350 align:middle line:90% 01:03:30.350 --> 01:03:33.680 align:middle line:84% at the end of the algorithm, since all of the evaluators 01:03:33.680 --> 01:03:37.530 align:middle line:84% rejected Dr. Jekyll, well, what we wrote up here, 01:03:37.530 --> 01:03:41.750 align:middle line:84% this invariant says that all of the evaluators 01:03:41.750 --> 01:03:44.550 align:middle line:84% have a candidate that's better than Dr. Jekyll. 01:03:44.550 --> 01:03:46.770 align:middle line:84% It was true when they rejected Dr. Jekyll 01:03:46.770 --> 01:03:50.720 align:middle line:84% and it remains true from then on. 01:03:50.720 --> 01:04:06.950 align:middle line:84% All evaluators have a candidate better than Dr. J. 01:04:06.950 --> 01:04:11.210 align:middle line:84% So we know we finish, and when we finish, all of the evaluators 01:04:11.210 --> 01:04:16.670 align:middle line:84% end up paired with someone better than Dr. J. 01:04:16.670 --> 01:04:18.840 align:middle line:84% But there aren't enough people for that. 01:04:18.840 --> 01:04:22.670 align:middle line:84% There are n evaluators and n applicants. 01:04:22.670 --> 01:04:25.970 align:middle line:84% And if Dr. Jekyll isn't paired with anyone, 01:04:25.970 --> 01:04:29.090 align:middle line:84% then there are only n-1 other applicants that 01:04:29.090 --> 01:04:32.360 align:middle line:90% can possibly have partners. 01:04:32.360 --> 01:04:36.860 align:middle line:84% So it can't be that all n of the evaluators 01:04:36.860 --> 01:04:39.860 align:middle line:84% finish with a partner better than Dr. J 01:04:39.860 --> 01:04:44.930 align:middle line:84% because all n of the evaluators, they can't all 01:04:44.930 --> 01:04:47.589 align:middle line:90% finish with anyone at all. 01:04:47.589 --> 01:04:48.089 align:middle line:90% Right? 01:04:48.089 --> 01:04:51.761 align:middle line:90% 01:04:51.761 --> 01:05:01.550 align:middle line:84% But there are only n-1 other applicants, 01:05:01.550 --> 01:05:18.110 align:middle line:84% so the n evaluators can't all have partners better than Dr. J. 01:05:18.110 --> 01:05:20.060 align:middle line:90% And there's our contradiction. 01:05:20.060 --> 01:05:23.250 align:middle line:84% So if we assume Dr. J. has no partner at the end, 01:05:23.250 --> 01:05:24.570 align:middle line:90% bad things happen. 01:05:24.570 --> 01:05:25.980 align:middle line:90% We find a contradiction. 01:05:25.980 --> 01:05:27.390 align:middle line:90% So that doesn't happen. 01:05:27.390 --> 01:05:30.240 align:middle line:84% So Dr. Jekyll does end up with a partner at the end, 01:05:30.240 --> 01:05:33.140 align:middle line:90% and, therefore, everyone does. 01:05:33.140 --> 01:05:34.900 align:middle line:84% So it returns a perfect matching. 01:05:34.900 --> 01:05:41.690 align:middle line:90% 01:05:41.690 --> 01:05:43.230 align:middle line:90% It returns a perfect matching. 01:05:43.230 --> 01:05:45.080 align:middle line:90% Everyone gets some partner. 01:05:45.080 --> 01:05:46.650 align:middle line:90% But is it stable? 01:05:46.650 --> 01:05:50.270 align:middle line:84% This is the part we really care about. 01:05:50.270 --> 01:05:56.900 align:middle line:90% Is it stable at the end? 01:05:56.900 --> 01:05:59.810 align:middle line:84% This is the part we really, truly care about. 01:05:59.810 --> 01:06:01.435 align:middle line:90% And let's prove that it is. 01:06:01.435 --> 01:06:05.510 align:middle line:90% 01:06:05.510 --> 01:06:11.600 align:middle line:84% So to see why, let's imagine what could possibly 01:06:11.600 --> 01:06:13.795 align:middle line:90% result in a rogue pair. 01:06:13.795 --> 01:06:16.670 align:middle line:90% 01:06:16.670 --> 01:06:20.360 align:middle line:90% Who can be rogue? 01:06:20.360 --> 01:06:23.250 align:middle line:84% The algorithm returns some perfect matching at the end. 01:06:23.250 --> 01:06:28.710 align:middle line:84% What does it mean for some pair of entities to be rogue? 01:06:28.710 --> 01:06:36.260 align:middle line:84% Well, I claim there are three kinds of applicants in relation 01:06:36.260 --> 01:06:38.670 align:middle line:84% to one of the particular evaluators. 01:06:38.670 --> 01:06:41.390 align:middle line:84% So if we think of Tufts as one of the evaluators-- 01:06:41.390 --> 01:06:47.150 align:middle line:84% Tufts Medical Center-- then some of the applicants, Tufts 01:06:47.150 --> 01:06:49.680 align:middle line:84% rejected at some point in the algorithm. 01:06:49.680 --> 01:06:53.570 align:middle line:84% Some of the applicants, Tufts never spoke to. 01:06:53.570 --> 01:06:57.230 align:middle line:84% And then one applicant, Tufts keeps until the end 01:06:57.230 --> 01:06:58.800 align:middle line:90% and ends up paired with. 01:06:58.800 --> 01:07:01.970 align:middle line:84% So let's consider each of those three kinds of pairings 01:07:01.970 --> 01:07:05.720 align:middle line:84% and show that Tufts can't be rogue with any of them. 01:07:05.720 --> 01:07:15.690 align:middle line:90% So let's assume Tufts rejected-- 01:07:15.690 --> 01:07:17.640 align:middle line:90% let's pick a generic example-- 01:07:17.640 --> 01:07:18.510 align:middle line:90% Tufts rejected. 01:07:18.510 --> 01:07:21.650 align:middle line:90% Dr. No. 01:07:21.650 --> 01:07:32.150 align:middle line:84% Let's say Tufts never spoke to Dr. Who? 01:07:32.150 --> 01:07:32.940 align:middle line:90% Who's that? 01:07:32.940 --> 01:07:34.380 align:middle line:90% I never spoke to them. 01:07:34.380 --> 01:07:42.265 align:middle line:84% And finally, Tufts is paired with the Good Doctor. 01:07:42.265 --> 01:07:46.010 align:middle line:90% 01:07:46.010 --> 01:07:49.160 align:middle line:84% These are the three kinds of people that 01:07:49.160 --> 01:07:50.910 align:middle line:90% can exist relative to Tufts. 01:07:50.910 --> 01:07:53.330 align:middle line:84% And let's show that none of these can be rogue. 01:07:53.330 --> 01:07:56.310 align:middle line:84% First of all, Tufts is paired with the Good Doctor. 01:07:56.310 --> 01:07:58.280 align:middle line:90% They're in our perfect matching. 01:07:58.280 --> 01:08:01.170 align:middle line:84% Rogue pairs are never in our perfect matching. 01:08:01.170 --> 01:08:04.220 align:middle line:84% They're pairs that are mutually preferred 01:08:04.220 --> 01:08:05.370 align:middle line:90% to the perfect matching. 01:08:05.370 --> 01:08:09.540 align:middle line:84% So this is never rogue by definition of rogue. 01:08:09.540 --> 01:08:11.950 align:middle line:84% If you're in the matching, you're not rogue. 01:08:11.950 --> 01:08:12.450 align:middle line:90% All right? 01:08:12.450 --> 01:08:14.530 align:middle line:84% So it's these other two cases that we care about. 01:08:14.530 --> 01:08:21.140 align:middle line:90% 01:08:21.140 --> 01:08:23.019 align:middle line:90% So first, let's look at Dr. No. 01:08:23.019 --> 01:08:32.569 align:middle line:90% 01:08:32.569 --> 01:08:33.300 align:middle line:90% All right. 01:08:33.300 --> 01:08:43.560 align:middle line:84% So Tufts rejected Dr. No at some point in the algorithm. 01:08:43.560 --> 01:08:45.870 align:middle line:84% And because of this invariant that we found, 01:08:45.870 --> 01:08:50.545 align:middle line:84% we know that Tufts ends up with someone better than Dr. No-- 01:08:50.545 --> 01:08:54.830 align:middle line:90% 01:08:54.830 --> 01:09:07.609 align:middle line:84% is paired with someone better than Dr. No. 01:09:07.609 --> 01:09:10.493 align:middle line:84% Because the moment an evaluator rejects someone, 01:09:10.493 --> 01:09:13.160 align:middle line:84% they know, they're always going to have someone better from then 01:09:13.160 --> 01:09:14.120 align:middle line:90% on. 01:09:14.120 --> 01:09:16.640 align:middle line:84% So Tufts and Dr. No can't possibly 01:09:16.640 --> 01:09:20.600 align:middle line:84% be rogue because Tufts is happier 01:09:20.600 --> 01:09:24.560 align:middle line:84% with who they end up with than they would be with Dr. No. 01:09:24.560 --> 01:09:27.859 align:middle line:84% Remember, rogue pair requires both members 01:09:27.859 --> 01:09:30.229 align:middle line:84% of the pair to prefer each other rather 01:09:30.229 --> 01:09:31.649 align:middle line:90% than their assigned partner. 01:09:31.649 --> 01:09:34.819 align:middle line:84% So since Tufts is happier with their assigned partner than with 01:09:34.819 --> 01:09:38.049 align:middle line:84% Dr. No, Tufts and Dr. No cannot be rogue. 01:09:38.049 --> 01:09:42.770 align:middle line:90% 01:09:42.770 --> 01:09:45.979 align:middle line:90% Does that make sense? 01:09:45.979 --> 01:09:46.859 align:middle line:90% All right. 01:09:46.859 --> 01:09:48.859 align:middle line:84% So we just use that invariant to say 01:09:48.859 --> 01:09:50.790 align:middle line:84% that since Tufts rejected Dr. No, 01:09:50.790 --> 01:09:54.050 align:middle line:84% their eventual partner is better than Dr. No. 01:09:54.050 --> 01:09:55.350 align:middle line:90% That's all that that is saying. 01:09:55.350 --> 01:09:56.520 align:middle line:90% What about the other side? 01:09:56.520 --> 01:09:59.960 align:middle line:90% What about Tufts with Dr. Who? 01:09:59.960 --> 01:10:03.530 align:middle line:84% Dr. Who never spoke with Tufts during the algorithm. 01:10:03.530 --> 01:10:04.670 align:middle line:90% All right? 01:10:04.670 --> 01:10:11.983 align:middle line:84% And since Dr. Who never spoke with Tufts-- 01:10:11.983 --> 01:10:15.225 align:middle line:90% 01:10:15.225 --> 01:10:17.100 align:middle line:84% well, remember what the applicants are doing. 01:10:17.100 --> 01:10:19.520 align:middle line:84% They're going down their list from the top. 01:10:19.520 --> 01:10:23.780 align:middle line:84% And since they stopped before they got to Tufts, wherever 01:10:23.780 --> 01:10:27.025 align:middle line:84% they stopped, they like better than they like Tufts. 01:10:27.025 --> 01:10:30.260 align:middle line:90% 01:10:30.260 --> 01:10:45.500 align:middle line:84% So Dr. Who likes their partner better than they like Tufts. 01:10:45.500 --> 01:10:53.880 align:middle line:84% And, therefore, Tufts with Dr. Who can't be rogue-- 01:10:53.880 --> 01:10:57.680 align:middle line:84% not rogue-- because this time, it's 01:10:57.680 --> 01:11:00.470 align:middle line:84% Dr. Who who's happier with their assignment 01:11:00.470 --> 01:11:04.280 align:middle line:90% then they would be with Tufts. 01:11:04.280 --> 01:11:08.510 align:middle line:84% So in this case, Tufts is happier 01:11:08.510 --> 01:11:09.750 align:middle line:90% with their current partner. 01:11:09.750 --> 01:11:13.110 align:middle line:84% In this case, Dr. Who is happier with their current partner. 01:11:13.110 --> 01:11:17.120 align:middle line:84% In both of these cases, Tufts with this person on the right 01:11:17.120 --> 01:11:18.560 align:middle line:90% cannot be rogue. 01:11:18.560 --> 01:11:21.110 align:middle line:84% So Tufts can't be rogue with anyone. 01:11:21.110 --> 01:11:22.675 align:middle line:90% So there are no rogue pairs. 01:11:22.675 --> 01:11:31.790 align:middle line:90% 01:11:31.790 --> 01:11:33.630 align:middle line:90% No rogue pairs can exist. 01:11:33.630 --> 01:11:37.220 align:middle line:84% The matching we get at the end is, in fact, stable. 01:11:37.220 --> 01:11:40.010 align:middle line:90% Did that make sense? 01:11:40.010 --> 01:11:42.170 align:middle line:90% Awesome. 01:11:42.170 --> 01:11:44.450 align:middle line:84% OK, let's return to this question of how good 01:11:44.450 --> 01:11:45.690 align:middle line:90% is this matching? 01:11:45.690 --> 01:11:47.300 align:middle line:84% Is this the one that makes everyone 01:11:47.300 --> 01:11:49.767 align:middle line:84% maximally happy or minimally happy or somewhere 01:11:49.767 --> 01:11:50.350 align:middle line:90% in the middle? 01:11:50.350 --> 01:11:53.870 align:middle line:90% 01:11:53.870 --> 01:11:56.270 align:middle line:90% Does anyone have an advantage? 01:11:56.270 --> 01:11:58.770 align:middle line:84% If you were participating in this algorithm, 01:11:58.770 --> 01:12:02.840 align:middle line:84% would you prefer to be an applicant or an evaluator? 01:12:02.840 --> 01:12:04.890 align:middle line:90% Well, it can go both ways. 01:12:04.890 --> 01:12:07.280 align:middle line:84% We already said that applicants' prospects only get worse 01:12:07.280 --> 01:12:09.530 align:middle line:84% over time, and evaluators' prospects only 01:12:09.530 --> 01:12:10.860 align:middle line:90% get better over time. 01:12:10.860 --> 01:12:13.670 align:middle line:84% So maybe it's better to be an evaluator. 01:12:13.670 --> 01:12:16.045 align:middle line:84% On the other hand, applicants start at the top 01:12:16.045 --> 01:12:17.420 align:middle line:84% and they stay as close to the top 01:12:17.420 --> 01:12:20.040 align:middle line:84% as they can until someone grudgingly says, 01:12:20.040 --> 01:12:23.000 align:middle line:90% OK, I guess I'll keep you. 01:12:23.000 --> 01:12:25.280 align:middle line:84% So maybe it's better to be an applicant 01:12:25.280 --> 01:12:31.040 align:middle line:84% because you're always asking the best partner you can possibly 01:12:31.040 --> 01:12:33.980 align:middle line:84% have, rather than the evaluators who have to wait around 01:12:33.980 --> 01:12:36.050 align:middle line:90% for people to come to them. 01:12:36.050 --> 01:12:39.256 align:middle line:84% So it's maybe not clear which side is preferable. 01:12:39.256 --> 01:12:44.060 align:middle line:90% 01:12:44.060 --> 01:12:48.140 align:middle line:84% So let me give a term so we can measure 01:12:48.140 --> 01:12:51.710 align:middle line:90% what we mean by preferable. 01:12:51.710 --> 01:13:00.730 align:middle line:84% First of all, let's say, so if E is an evaluator 01:13:00.730 --> 01:13:08.830 align:middle line:84% and A is an applicant, let's say that E and A are feasible 01:13:08.830 --> 01:13:16.883 align:middle line:84% partners if and only if it's possible. 01:13:16.883 --> 01:13:20.680 align:middle line:90% 01:13:20.680 --> 01:13:27.285 align:middle line:84% to put E and A together in a stable matching. 01:13:27.285 --> 01:13:32.710 align:middle line:90% 01:13:32.710 --> 01:13:34.990 align:middle line:84% Not necessarily the stable matching 01:13:34.990 --> 01:13:36.910 align:middle line:90% that the algorithm gives. 01:13:36.910 --> 01:13:39.370 align:middle line:84% But if there's any stable matching 01:13:39.370 --> 01:13:41.330 align:middle line:90% that pairs E with a together. 01:13:41.330 --> 01:13:44.770 align:middle line:84% Then we'll say that they are feasible partners. 01:13:44.770 --> 01:13:46.180 align:middle line:90% All right? 01:13:46.180 --> 01:13:50.950 align:middle line:84% And now we have the following theorems. 01:13:50.950 --> 01:14:01.158 align:middle line:84% The Gale-Shapley algorithm pairs every applicant 01:14:01.158 --> 01:14:09.330 align:middle line:84% with their most preferred feasible partner. 01:14:09.330 --> 01:14:15.610 align:middle line:90% 01:14:15.610 --> 01:14:18.390 align:middle line:84% So each applicant doesn't get their top choice. 01:14:18.390 --> 01:14:20.890 align:middle line:84% We know they can't each get their first choice because there 01:14:20.890 --> 01:14:23.200 align:middle line:90% might be conflicts there. 01:14:23.200 --> 01:14:25.700 align:middle line:84% But each applicant, it turns out, 01:14:25.700 --> 01:14:28.300 align:middle line:84% gets the best possible choice they could ever 01:14:28.300 --> 01:14:32.920 align:middle line:84% hope to get among all possible stable matchings. 01:14:32.920 --> 01:14:36.850 align:middle line:84% So up here on the board, we see that Applicant A 01:14:36.850 --> 01:14:41.980 align:middle line:84% is paired with Evaluator 2 and not with 1 or 3. 01:14:41.980 --> 01:14:44.830 align:middle line:84% And what this theorem says is that A can never 01:14:44.830 --> 01:14:47.290 align:middle line:84% be paired with 1 and can never be paired 01:14:47.290 --> 01:14:49.940 align:middle line:90% with 3 in any stable matching. 01:14:49.940 --> 01:14:52.520 align:middle line:84% There is no stable matching that pairs A with 1. 01:14:52.520 --> 01:14:55.150 align:middle line:84% There is no stable matching that pairs A with 3. 01:14:55.150 --> 01:15:00.670 align:middle line:84% A paired with 2 is the highest-preference partner 01:15:00.670 --> 01:15:03.100 align:middle line:90% that A has that is feasible. 01:15:03.100 --> 01:15:07.030 align:middle line:84% And Gale-Shapley gives him that partner. 01:15:07.030 --> 01:15:10.120 align:middle line:84% So every evaluator gets the best partner they could possibly 01:15:10.120 --> 01:15:13.180 align:middle line:90% get in any stable matching. 01:15:13.180 --> 01:15:15.500 align:middle line:84% I personally find this surprising. 01:15:15.500 --> 01:15:19.550 align:middle line:84% Like often when we have some optimization problem 01:15:19.550 --> 01:15:21.220 align:middle line:84% but we have lots of different metrics 01:15:21.220 --> 01:15:23.230 align:middle line:90% that we're trying to optimize-- 01:15:23.230 --> 01:15:26.330 align:middle line:84% like Candidate A wants to get their best possible partner, 01:15:26.330 --> 01:15:29.170 align:middle line:84% Candidate B wants to get their best possible partner-- 01:15:29.170 --> 01:15:33.580 align:middle line:84% and to me, it feels intuitive that maybe these desires 01:15:33.580 --> 01:15:35.200 align:middle line:90% might conflict with each other. 01:15:35.200 --> 01:15:39.670 align:middle line:84% Like maybe A and B both have Evaluator 3 01:15:39.670 --> 01:15:42.353 align:middle line:84% as their optimal partner, and there 01:15:42.353 --> 01:15:44.020 align:middle line:84% are just two different stable matchings, 01:15:44.020 --> 01:15:47.560 align:middle line:84% one that pairs A with 3, one that pairs B with 3. 01:15:47.560 --> 01:15:51.700 align:middle line:84% So it's kind of weird to me that each candidate can 01:15:51.700 --> 01:15:56.990 align:middle line:84% be given their optimal feasible partner all at the same time 01:15:56.990 --> 01:15:59.170 align:middle line:84% and there's no conflict among them. 01:15:59.170 --> 01:16:02.140 align:middle line:84% So I find this a little bit counterintuitive 01:16:02.140 --> 01:16:03.140 align:middle line:90% for that reason. 01:16:03.140 --> 01:16:07.690 align:middle line:84% Beautiful fact, but a little counterintuitive. 01:16:07.690 --> 01:16:20.184 align:middle line:84% And theorem-- Gale-Shapley pairs every evaluator 01:16:20.184 --> 01:16:27.055 align:middle line:84% with their, this time, least-preferred feasible 01:16:27.055 --> 01:16:27.555 align:middle line:90% partner. 01:16:27.555 --> 01:16:33.250 align:middle line:90% 01:16:33.250 --> 01:16:36.070 align:middle line:84% So exactly the same idea, but this time, 01:16:36.070 --> 01:16:37.900 align:middle line:84% the evaluators, instead of coming out 01:16:37.900 --> 01:16:39.460 align:middle line:84% as best as they possibly can, they 01:16:39.460 --> 01:16:42.015 align:middle line:84% come out as worst as they possibly can. 01:16:42.015 --> 01:16:44.710 align:middle line:90% 01:16:44.710 --> 01:16:50.020 align:middle line:84% Let's say because Evaluator 1 ended up with Partner C, 01:16:50.020 --> 01:16:52.870 align:middle line:84% there is no stable matching that pairs 1 with anyone 01:16:52.870 --> 01:16:56.240 align:middle line:84% worse than C. There is no stable matching that pairs 1 with B. 01:16:56.240 --> 01:17:00.250 align:middle line:84% There is no stable matching that pairs 1 with A. 01:17:00.250 --> 01:17:04.690 align:middle line:84% So it's best for all of the applicants at the same time, 01:17:04.690 --> 01:17:08.560 align:middle line:84% and, simultaneously, worst for all 01:17:08.560 --> 01:17:11.270 align:middle line:84% of the evaluators at the same time. 01:17:11.270 --> 01:17:13.930 align:middle line:84% This single matching that Gale-Shapley returns has 01:17:13.930 --> 01:17:15.525 align:middle line:90% all of these properties in it. 01:17:15.525 --> 01:17:18.850 align:middle line:90% 01:17:18.850 --> 01:17:21.200 align:middle line:84% Which brings us back to the question earlier, 01:17:21.200 --> 01:17:24.880 align:middle line:84% if we were to run this algorithm in reverse 01:17:24.880 --> 01:17:30.160 align:middle line:84% by swapping the roles of the evaluators and the applicants, 01:17:30.160 --> 01:17:32.980 align:middle line:84% we're going to move from the matching that 01:17:32.980 --> 01:17:37.138 align:middle line:84% is best for this set to the one that's best for the other set, 01:17:37.138 --> 01:17:38.930 align:middle line:84% and the one that's worst for the first set, 01:17:38.930 --> 01:17:41.500 align:middle line:84% to the one that's best for the other set. 01:17:41.500 --> 01:17:43.330 align:middle line:84% And that's why usually, you're going 01:17:43.330 --> 01:17:45.380 align:middle line:84% to get two different matchings out of it. 01:17:45.380 --> 01:17:47.490 align:middle line:84% Because if there are multiple matchings 01:17:47.490 --> 01:17:51.550 align:middle line:84% and multiple stable matchings at all for this set of preferences, 01:17:51.550 --> 01:17:56.830 align:middle line:84% the worst and the best are going to be different from each other. 01:17:56.830 --> 01:17:58.280 align:middle line:90% Do these ideas make sense? 01:17:58.280 --> 01:18:04.300 align:middle line:84% We haven't proven them yet, but do the ideas make sense? 01:18:04.300 --> 01:18:05.410 align:middle line:90% All right. 01:18:05.410 --> 01:18:07.690 align:middle line:84% Let me give you just a brief hint 01:18:07.690 --> 01:18:09.950 align:middle line:84% at how we might go about proving this. 01:18:09.950 --> 01:18:13.810 align:middle line:84% We'll prove it more precisely in recitation tomorrow. 01:18:13.810 --> 01:18:15.543 align:middle line:90% But the basic idea-- 01:18:15.543 --> 01:18:23.170 align:middle line:90% 01:18:23.170 --> 01:18:24.705 align:middle line:90% pause for dramatic effect-- 01:18:24.705 --> 01:18:30.880 align:middle line:90% 01:18:30.880 --> 01:18:32.930 align:middle line:90% the basic idea is going to be-- 01:18:32.930 --> 01:18:33.890 align:middle line:90% oh, I'm holding chalk. 01:18:33.890 --> 01:18:42.910 align:middle line:84% I found it-- one more key invariant, so invariant 01:18:42.910 --> 01:18:47.050 align:middle line:90% for our Gale-Shapley algorithm. 01:18:47.050 --> 01:18:57.580 align:middle line:84% So if an evaluator ever rejects an applicant A, 01:18:57.580 --> 01:19:03.893 align:middle line:84% then EA are not feasible partners. 01:19:03.893 --> 01:19:07.270 align:middle line:90% 01:19:07.270 --> 01:19:10.810 align:middle line:84% So if E rejects A at any time during the Gale-Shapley 01:19:10.810 --> 01:19:14.890 align:middle line:84% algorithm, then there does not exist any stable matching 01:19:14.890 --> 01:19:17.850 align:middle line:84% at all that puts E with A together. 01:19:17.850 --> 01:19:20.590 align:middle line:90% 01:19:20.590 --> 01:19:24.640 align:middle line:84% It turns out we can prove this as an invariant of our state 01:19:24.640 --> 01:19:26.260 align:middle line:90% machine. 01:19:26.260 --> 01:19:29.530 align:middle line:84% Very briefly, let's see if we can do that. 01:19:29.530 --> 01:19:34.810 align:middle line:84% OK, so, whew-- also this is true for all evaluators 01:19:34.810 --> 01:19:36.380 align:middle line:90% and for all applicants. 01:19:36.380 --> 01:19:39.740 align:middle line:84% If any evaluator rejects any applicant at any time, 01:19:39.740 --> 01:19:42.010 align:middle line:84% then they're not feasible partners. 01:19:42.010 --> 01:19:44.500 align:middle line:84% So the heart of the proof is let's 01:19:44.500 --> 01:19:55.958 align:middle line:84% assume that an Evaluator E rejects an Applicant A today, 01:19:55.958 --> 01:19:58.380 align:middle line:90% so we've newly rejected someone. 01:19:58.380 --> 01:20:01.040 align:middle line:84% And so now we're going to show that E and A can't be feasible 01:20:01.040 --> 01:20:11.750 align:middle line:90% partners in favor of A prime. 01:20:11.750 --> 01:20:16.220 align:middle line:84% So if E rejects this applicant in favor of that applicant, 01:20:16.220 --> 01:20:20.630 align:middle line:84% well then we know that E prefers the new applicant 01:20:20.630 --> 01:20:24.050 align:middle line:84% over the old applicant because that's the only reason E would 01:20:24.050 --> 01:20:27.020 align:middle line:90% reject one for the other. 01:20:27.020 --> 01:20:48.790 align:middle line:84% And then the main observation is that in any hypothetical stable 01:20:48.790 --> 01:20:52.250 align:middle line:84% matching-- not necessarily the one that comes from Gale-Shapley 01:20:52.250 --> 01:20:55.930 align:middle line:84% but in any possible stable matching you try to set up where 01:20:55.930 --> 01:20:59.620 align:middle line:84% A matches with E, and then necessarily, 01:20:59.620 --> 01:21:03.820 align:middle line:84% A prime matches with someone else-- 01:21:03.820 --> 01:21:13.650 align:middle line:84% you can prove that E and A prime are rogue. 01:21:13.650 --> 01:21:16.660 align:middle line:90% 01:21:16.660 --> 01:21:21.370 align:middle line:84% So because E rejected A prime in favor of A 01:21:21.370 --> 01:21:24.160 align:middle line:84% on some day in the algorithm, you 01:21:24.160 --> 01:21:26.980 align:middle line:84% can show that any time you try to pair A with E 01:21:26.980 --> 01:21:29.290 align:middle line:84% together in a stable matching, actually, it's 01:21:29.290 --> 01:21:31.880 align:middle line:84% not stable because E and A prime are rogue. 01:21:31.880 --> 01:21:33.550 align:middle line:90% They each prefer each other. 01:21:33.550 --> 01:21:36.050 align:middle line:84% You'll see the details of that in recitation tomorrow. 01:21:36.050 --> 01:21:37.920 align:middle line:90% Thank you so much. 01:21:37.920 --> 01:21:43.000 align:middle line:90%