WEBVTT 00:00:00.000 --> 00:00:12.584 align:middle line:84% [SQUEAKING] [RUSTLING] [CLICKING] 00:00:12.584 --> 00:00:15.250 align:middle line:84% JUSTIN SOLOMON: Right, so today is going to be our first, 00:00:15.250 --> 00:00:17.050 align:middle line:84% I believe, of two problem sessions 00:00:17.050 --> 00:00:18.670 align:middle line:90% covering dynamic programming. 00:00:18.670 --> 00:00:21.032 align:middle line:90% 00:00:21.032 --> 00:00:22.490 align:middle line:84% I've learned dynamic programming is 00:00:22.490 --> 00:00:24.698 align:middle line:84% one of these interesting parts of an algorithms class 00:00:24.698 --> 00:00:26.960 align:middle line:84% where, somehow, the people that are really good at it 00:00:26.960 --> 00:00:28.730 align:middle line:84% are completely disjoint with the people that 00:00:28.730 --> 00:00:31.063 align:middle line:84% are good at all the other parts of the algorithms class. 00:00:31.063 --> 00:00:33.290 align:middle line:84% So for some of you guys, that might be promising, 00:00:33.290 --> 00:00:35.750 align:middle line:84% and for others, maybe a little bit less so. 00:00:35.750 --> 00:00:38.000 align:middle line:84% So maybe we'll spend just a minute or two reviewing 00:00:38.000 --> 00:00:40.490 align:middle line:84% the basic ideas we're going to apply in these problems 00:00:40.490 --> 00:00:43.640 align:middle line:84% because they'll follow, more or less, the same template. 00:00:43.640 --> 00:00:45.560 align:middle line:84% Although, of course, as usual in 6.006, 00:00:45.560 --> 00:00:49.370 align:middle line:84% we like to put some interesting window dressing around it 00:00:49.370 --> 00:00:52.200 align:middle line:84% so that it's not totally obvious what you're doing. 00:00:52.200 --> 00:00:54.960 align:middle line:84% And then we'll do a bunch of sample problems. 00:00:54.960 --> 00:00:55.460 align:middle line:90% Right. 00:00:55.460 --> 00:00:58.880 align:middle line:84% So let's talk a little bit about dynamic programming 00:00:58.880 --> 00:01:01.520 align:middle line:90% and the basic idea here. 00:01:01.520 --> 00:01:05.209 align:middle line:84% So, dynamic programming is kind of a funny outlier in 6.006 00:01:05.209 --> 00:01:06.138 align:middle line:90% in that-- 00:01:06.138 --> 00:01:08.430 align:middle line:84% for example, in the data structures part of the course, 00:01:08.430 --> 00:01:11.260 align:middle line:90% we learned, like, what-- 00:01:11.260 --> 00:01:13.740 align:middle line:84% now I'm struggling to think of a data structure-- 00:01:13.740 --> 00:01:16.530 align:middle line:84% like a useful-- like trees and arrays or whatever. 00:01:16.530 --> 00:01:18.530 align:middle line:84% And these are actually things that you can code. 00:01:18.530 --> 00:01:22.610 align:middle line:84% if you look and see if there are-- 00:01:22.610 --> 00:01:24.590 align:middle line:84% well, plausibly, it could be an implementation 00:01:24.590 --> 00:01:26.810 align:middle line:90% of a tree in there somewhere. 00:01:26.810 --> 00:01:28.280 align:middle line:84% And so these are useful algorithms 00:01:28.280 --> 00:01:29.930 align:middle line:84% that you can maybe even read the pseudocode. 00:01:29.930 --> 00:01:31.555 align:middle line:84% And there's a universe where you really 00:01:31.555 --> 00:01:33.740 align:middle line:84% do translate that pseudocode into something 00:01:33.740 --> 00:01:35.567 align:middle line:90% inside of your laptop. 00:01:35.567 --> 00:01:37.400 align:middle line:84% Dynamic programming is a little bit less so. 00:01:37.400 --> 00:01:38.420 align:middle line:90% This is more of a meta-- 00:01:38.420 --> 00:01:40.337 align:middle line:84% I don't know if you'd call it a meta algorithm 00:01:40.337 --> 00:01:42.590 align:middle line:84% or problem solving approach or what, 00:01:42.590 --> 00:01:44.290 align:middle line:84% but it's not like you somehow say, 00:01:44.290 --> 00:01:46.040 align:middle line:84% I'm going to apply the dynamic programming 00:01:46.040 --> 00:01:48.030 align:middle line:90% algorithm to this problem. 00:01:48.030 --> 00:01:51.410 align:middle line:84% But rather, it's sort of this big class of things that all 00:01:51.410 --> 00:01:55.100 align:middle line:84% follow a similar template or sort of approach to thinking 00:01:55.100 --> 00:01:58.790 align:middle line:84% about problem solving, which I think sort of explains why, 00:01:58.790 --> 00:02:01.940 align:middle line:84% actually, in some sense, the last couple of lectures that 00:02:01.940 --> 00:02:04.762 align:middle line:84% you've seen-- and, I guess, if I'm getting the time sequence 00:02:04.762 --> 00:02:07.220 align:middle line:84% of our course right, the next couple of years that you will 00:02:07.220 --> 00:02:08.815 align:middle line:90% see-- 00:02:08.815 --> 00:02:10.190 align:middle line:84% and the problem sessions actually 00:02:10.190 --> 00:02:13.280 align:middle line:84% start to coincide in the sense that when Erik was teaching 00:02:13.280 --> 00:02:16.080 align:middle line:84% you guys dynamic programming, how did he do it? 00:02:16.080 --> 00:02:17.540 align:middle line:84% Well, he didn't write down-- well, 00:02:17.540 --> 00:02:18.800 align:middle line:84% he sort of wrote down some template 00:02:18.800 --> 00:02:20.300 align:middle line:84% for dynamic programming, but then we just did 00:02:20.300 --> 00:02:21.710 align:middle line:90% a bunch of sample problems. 00:02:21.710 --> 00:02:23.812 align:middle line:84% And that's exactly what we're going to do today. 00:02:23.812 --> 00:02:25.520 align:middle line:84% So, somehow, all of these things are just 00:02:25.520 --> 00:02:28.610 align:middle line:84% going to converge in this part of our course 00:02:28.610 --> 00:02:30.770 align:middle line:84% because dynamic programming, it's 00:02:30.770 --> 00:02:35.203 align:middle line:84% really more of a way of life than any particular algorithm. 00:02:35.203 --> 00:02:36.620 align:middle line:84% And this is a pattern that I think 00:02:36.620 --> 00:02:38.623 align:middle line:84% you see a lot in advanced algorithms. 00:02:38.623 --> 00:02:40.040 align:middle line:84% Like, for example, in my universe, 00:02:40.040 --> 00:02:43.360 align:middle line:84% in numerical analysis, when you talk about the ADMM algorithm, 00:02:43.360 --> 00:02:45.110 align:middle line:84% it's actually a totally useless algorithm. 00:02:45.110 --> 00:02:48.350 align:middle line:84% What matters is applying it to a particular problem. 00:02:48.350 --> 00:02:51.500 align:middle line:84% And this is sort of, I think, a more mature or grown up 00:02:51.500 --> 00:02:53.030 align:middle line:84% way to think about a lot of things 00:02:53.030 --> 00:02:56.900 align:middle line:84% in algorithms, that pretty soon, this sort of general purpose 00:02:56.900 --> 00:02:59.340 align:middle line:84% stuff that's useful all the time, 00:02:59.340 --> 00:03:02.150 align:middle line:84% I think, it starts to disperse a little bit in favor 00:03:02.150 --> 00:03:03.782 align:middle line:84% of different patterns and mechanisms 00:03:03.782 --> 00:03:05.240 align:middle line:84% that you're used to thinking about. 00:03:05.240 --> 00:03:07.100 align:middle line:84% So there's my 10-second, sort of, 00:03:07.100 --> 00:03:09.320 align:middle line:84% philosophical introduction to what we're doing, 00:03:09.320 --> 00:03:10.850 align:middle line:84% during which I've managed to chase 00:03:10.850 --> 00:03:14.870 align:middle line:90% this table across the room. 00:03:14.870 --> 00:03:15.860 align:middle line:90% You know, I played-- 00:03:15.860 --> 00:03:18.183 align:middle line:84% I did college on the west coast, and I 00:03:18.183 --> 00:03:19.850 align:middle line:84% thought I was going to be a music major. 00:03:19.850 --> 00:03:21.517 align:middle line:84% And there was a piano master class where 00:03:21.517 --> 00:03:23.720 align:middle line:84% we forgot to put the little clips on the wheels 00:03:23.720 --> 00:03:26.080 align:middle line:84% and there was an earthquake, and I just 00:03:26.080 --> 00:03:28.580 align:middle line:84% thought I was really nervous because the piano was literally 00:03:28.580 --> 00:03:30.980 align:middle line:90% slipping away from me. 00:03:30.980 --> 00:03:35.160 align:middle line:84% I can never think of that Chopin nocturne in quite the same way. 00:03:35.160 --> 00:03:38.570 align:middle line:84% But in any event, in dynamic programming, 00:03:38.570 --> 00:03:41.240 align:middle line:84% Erik laid out for you guys a particular, sort of, 00:03:41.240 --> 00:03:46.160 align:middle line:84% set of steps that are a useful problem-solving approach 00:03:46.160 --> 00:03:47.738 align:middle line:84% in the dynamic programming universe. 00:03:47.738 --> 00:03:49.280 align:middle line:84% In today's problem session, I'm going 00:03:49.280 --> 00:03:51.770 align:middle line:84% to try and help you guys translate a little bit 00:03:51.770 --> 00:03:55.040 align:middle line:84% from this template to what it means to actually write code 00:03:55.040 --> 00:03:56.990 align:middle line:84% to implement a dynamic programming algorithm 00:03:56.990 --> 00:04:01.260 align:middle line:84% because I think it's a little easy to forget that here. 00:04:01.260 --> 00:04:03.860 align:middle line:84% But, on the other hand, on your homework, 00:04:03.860 --> 00:04:06.480 align:middle line:84% when you're writing out answers to algorithms problem, 00:04:06.480 --> 00:04:09.860 align:middle line:84% it's perfectly fine to follow this template even letter-- 00:04:09.860 --> 00:04:13.058 align:middle line:84% I guess-- literally letter for letter and answer each 00:04:13.058 --> 00:04:13.850 align:middle line:90% of these questions. 00:04:13.850 --> 00:04:17.600 align:middle line:84% And then the remaining glue that you need to actually write 00:04:17.600 --> 00:04:19.910 align:middle line:84% the code is not terribly exciting 00:04:19.910 --> 00:04:22.980 align:middle line:84% from an algorithms theory perspective. 00:04:22.980 --> 00:04:25.010 align:middle line:84% So the basic idea here is that there's 00:04:25.010 --> 00:04:27.560 align:middle line:84% a lot of different problems that can be written recursively, 00:04:27.560 --> 00:04:29.580 align:middle line:90% in some sense. 00:04:29.580 --> 00:04:32.810 align:middle line:84% Certainly, we've encountered many of those in this course. 00:04:32.810 --> 00:04:34.310 align:middle line:84% In fact, I think the bias in the way 00:04:34.310 --> 00:04:35.850 align:middle line:84% that we've presented algorithms that 00:04:35.850 --> 00:04:39.420 align:middle line:84% don't have to be recursive is to write them in a recursive way. 00:04:39.420 --> 00:04:43.370 align:middle line:84% And the point here is that when you have a recursive call 00:04:43.370 --> 00:04:46.790 align:middle line:84% and you repeat something, you give the function 00:04:46.790 --> 00:04:48.680 align:middle line:84% the same input more than one time, 00:04:48.680 --> 00:04:51.542 align:middle line:84% you might as well remember what you got the last time you saw 00:04:51.542 --> 00:04:53.000 align:middle line:84% that input, and then you don't have 00:04:53.000 --> 00:04:54.290 align:middle line:90% to do that computation again. 00:04:54.290 --> 00:04:57.740 align:middle line:84% Really, in one sentence, I think that's roughly the logic behind 00:04:57.740 --> 00:05:00.320 align:middle line:84% all these dynamic programming things. 00:05:00.320 --> 00:05:02.960 align:middle line:84% So there's no reason to be too redundant with lecture. 00:05:02.960 --> 00:05:05.690 align:middle line:84% For just the 10-second overview, I 00:05:05.690 --> 00:05:08.150 align:middle line:84% think that there's an example which is simultaneously 00:05:08.150 --> 00:05:12.050 align:middle line:84% good and misleading, which is this Fibonacci sequence. 00:05:12.050 --> 00:05:15.140 align:middle line:84% It's good in the sense that the logic of dynamic programming 00:05:15.140 --> 00:05:16.010 align:middle line:90% is really easy. 00:05:16.010 --> 00:05:20.075 align:middle line:84% It's bad in that the runtime is kind of weird to think about. 00:05:20.075 --> 00:05:21.950 align:middle line:84% But remember, though, your Fibonacci sequence 00:05:21.950 --> 00:05:27.380 align:middle line:84% looks something like f of k equals f of k minus 1 00:05:27.380 --> 00:05:30.750 align:middle line:90% plus f of k minus 2. 00:05:30.750 --> 00:05:34.740 align:middle line:84% And if you look at your, sort of, recursive call tree here-- 00:05:34.740 --> 00:05:37.490 align:middle line:84% like, let's say that I do k equals 4. 00:05:37.490 --> 00:05:39.800 align:middle line:90% Then it's going to call-- 00:05:39.800 --> 00:05:43.040 align:middle line:84% my function f is going to have to evaluate it at 3 and 2. 00:05:43.040 --> 00:05:46.880 align:middle line:84% And then the 3 is going to evaluate at 2 and 1, and so on. 00:05:46.880 --> 00:05:51.050 align:middle line:84% And the thing to notice is that when I call f of 4-- 00:05:51.050 --> 00:05:54.740 align:middle line:84% or, rather, f of 3 here, if there were 3 somewhere else 00:05:54.740 --> 00:05:56.360 align:middle line:84% in my tree, I get the same number, so, 00:05:56.360 --> 00:05:59.578 align:middle line:84% in particular, f of 2 and f of 2. 00:05:59.578 --> 00:06:01.370 align:middle line:84% Both of these are going to take some amount 00:06:01.370 --> 00:06:03.328 align:middle line:84% of algorithmic work, but if just the first time 00:06:03.328 --> 00:06:05.780 align:middle line:84% I see a 2 I have a little piece of scratch paper 00:06:05.780 --> 00:06:08.870 align:middle line:84% and I say, oh, any time I see k equals 00:06:08.870 --> 00:06:10.400 align:middle line:84% 2, just return this number rather 00:06:10.400 --> 00:06:12.980 align:middle line:84% than doing recursive calls, then, in effect, 00:06:12.980 --> 00:06:16.220 align:middle line:84% if there's any subtree underneath this thing, 00:06:16.220 --> 00:06:19.010 align:middle line:84% I've just pruned it from my tree. 00:06:19.010 --> 00:06:22.620 align:middle line:84% And so that's the basic logic here. 00:06:22.620 --> 00:06:24.500 align:middle line:84% And that's basically the paradigm 00:06:24.500 --> 00:06:30.790 align:middle line:84% that's going on in this SRTBOT acronym, which 00:06:30.790 --> 00:06:34.960 align:middle line:84% is you first take your problem and divide it into subproblems. 00:06:34.960 --> 00:06:36.080 align:middle line:90% That is mysterious. 00:06:36.080 --> 00:06:37.150 align:middle line:90% Why is this board moving? 00:06:37.150 --> 00:06:40.276 align:middle line:90% 00:06:40.276 --> 00:06:42.901 align:middle line:84% Oh, there's a phone in my pocket and I bumped against the wall. 00:06:42.901 --> 00:06:48.302 align:middle line:90% 00:06:48.302 --> 00:06:50.750 align:middle line:90% I'm not used to this classroom. 00:06:50.750 --> 00:06:52.510 align:middle line:90% Right. 00:06:52.510 --> 00:06:53.010 align:middle line:90% Yeah. 00:06:53.010 --> 00:06:54.385 align:middle line:84% So the first thing you want to do 00:06:54.385 --> 00:06:58.272 align:middle line:84% is to write my problem as this sort of form. 00:06:58.272 --> 00:07:00.480 align:middle line:84% Notice just that we've done this a lot in this class, 00:07:00.480 --> 00:07:01.855 align:middle line:84% we've written things recursively. 00:07:01.855 --> 00:07:04.320 align:middle line:84% The difference here is the sort of argument 00:07:04.320 --> 00:07:06.360 align:middle line:84% that goes into recursion is typically, maybe, 00:07:06.360 --> 00:07:10.140 align:middle line:84% a little simpler than putting some giant data structure 00:07:10.140 --> 00:07:11.840 align:middle line:84% inside of there or something like that. 00:07:11.840 --> 00:07:13.680 align:middle line:84% So, for instance, merge sort, you 00:07:13.680 --> 00:07:14.980 align:middle line:90% could write in this paradigm. 00:07:14.980 --> 00:07:16.730 align:middle line:84% I guess we covered that, but it's probably 00:07:16.730 --> 00:07:19.370 align:middle line:84% not the most natural way to think about merge sort. 00:07:19.370 --> 00:07:22.290 align:middle line:84% Then we need to relate our subproblems to each other. 00:07:22.290 --> 00:07:24.920 align:middle line:84% So, for instance, in the Fibonacci sequence problem, 00:07:24.920 --> 00:07:26.750 align:middle line:84% I just gave you the relation that-- 00:07:26.750 --> 00:07:28.500 align:middle line:90% what defines the problem. 00:07:28.500 --> 00:07:32.840 align:middle line:84% Incidentally, this is, what, a model for the reproduction 00:07:32.840 --> 00:07:34.550 align:middle line:84% of rabbits, I think, if I remember 00:07:34.550 --> 00:07:36.710 align:middle line:84% reading the history of the Fibonacci sequence. 00:07:36.710 --> 00:07:39.250 align:middle line:90% 00:07:39.250 --> 00:07:41.505 align:middle line:84% And then, I think, to me, the most-- 00:07:41.505 --> 00:07:44.130 align:middle line:84% not necessarily unnatural-- but I think the thing that maybe is 00:07:44.130 --> 00:07:46.422 align:middle line:84% hardest to translate to an algorithm if you're thinking 00:07:46.422 --> 00:07:47.760 align:middle line:90% about writing code is this-- 00:07:47.760 --> 00:07:50.170 align:middle line:84% oh, man, this is going to be a problem-- 00:07:50.170 --> 00:07:53.430 align:middle line:90% this idea of topological order. 00:07:53.430 --> 00:07:57.090 align:middle line:84% The basic idea here is that if f of 1 depended on f of 2, 00:07:57.090 --> 00:08:01.110 align:middle line:84% and f of 2 depended on f of 1, I'd be in a lot of trouble, 00:08:01.110 --> 00:08:03.510 align:middle line:84% right, because somehow my tree would never 00:08:03.510 --> 00:08:06.210 align:middle line:84% converge, for one thing, if I made these recursive calls 00:08:06.210 --> 00:08:09.090 align:middle line:84% and I'd never be able to memoize or, kind of, 00:08:09.090 --> 00:08:10.910 align:middle line:90% remember a value when I move on. 00:08:10.910 --> 00:08:11.410 align:middle line:90% Right? 00:08:11.410 --> 00:08:12.910 align:middle line:84% And so the idea here is that there's 00:08:12.910 --> 00:08:14.370 align:middle line:84% some ordering of my subproblem so 00:08:14.370 --> 00:08:16.630 align:middle line:90% that I can build up a solution. 00:08:16.630 --> 00:08:18.460 align:middle line:84% And there's, sort of, two dual ways 00:08:18.460 --> 00:08:20.490 align:middle line:84% to think about why that's useful. 00:08:20.490 --> 00:08:24.530 align:middle line:84% So in the memoization universe, what do I do? 00:08:24.530 --> 00:08:27.430 align:middle line:84% I just add an if statement saying if I've already 00:08:27.430 --> 00:08:29.560 align:middle line:90% evaluated f of k, return it. 00:08:29.560 --> 00:08:31.640 align:middle line:90% That's perfectly fine. 00:08:31.640 --> 00:08:34.030 align:middle line:84% The other thing I can do is if I write my problems 00:08:34.030 --> 00:08:37.289 align:middle line:84% in topological order, then I can sort of 00:08:37.289 --> 00:08:40.950 align:middle line:84% go in the reverse direction and build up my memoization table. 00:08:40.950 --> 00:08:45.120 align:middle line:84% So, for instance, for the Fibonacci sequence problem, 00:08:45.120 --> 00:08:48.630 align:middle line:84% I could do f of 1 and then f of 2 and then f of 3 and f of 4 00:08:48.630 --> 00:08:51.270 align:middle line:84% all the way until I get to the k value that I actually wanted. 00:08:51.270 --> 00:08:53.400 align:middle line:84% And those are just duals of the same coin. 00:08:53.400 --> 00:08:55.715 align:middle line:84% They're exactly the same approach. 00:08:55.715 --> 00:08:57.090 align:middle line:84% Although the memoization version, 00:08:57.090 --> 00:08:58.860 align:middle line:84% sometimes you can prune out subproblems 00:08:58.860 --> 00:09:00.610 align:middle line:84% that you didn't actually need to solve. 00:09:00.610 --> 00:09:03.430 align:middle line:84% So, for instance, maybe this was f of k minus 7, 00:09:03.430 --> 00:09:06.340 align:middle line:84% and so I can skip a few indices in my array. 00:09:06.340 --> 00:09:08.835 align:middle line:84% I don't think, typically, that has a big effect on runtime 00:09:08.835 --> 00:09:10.210 align:middle line:84% for the problems that we've seen, 00:09:10.210 --> 00:09:13.690 align:middle line:84% but it could, plausibly, in some universal. 00:09:13.690 --> 00:09:15.100 align:middle line:84% I'd have to think about a problem 00:09:15.100 --> 00:09:18.440 align:middle line:90% where that makes a difference. 00:09:18.440 --> 00:09:18.940 align:middle line:90% Right. 00:09:18.940 --> 00:09:20.773 align:middle line:84% And then I think the BOT part of SRTBOT 00:09:20.773 --> 00:09:22.190 align:middle line:84% is a little easier to think about. 00:09:22.190 --> 00:09:25.810 align:middle line:84% You have to make sure that this recursion has a base case, 00:09:25.810 --> 00:09:27.730 align:middle line:84% like when is this thing going to stop. 00:09:27.730 --> 00:09:28.880 align:middle line:90% That's exactly the same. 00:09:28.880 --> 00:09:32.090 align:middle line:84% It's just any recursive algorithm. 00:09:32.090 --> 00:09:35.590 align:middle line:84% The O for original, I think, is a little bit 00:09:35.590 --> 00:09:38.050 align:middle line:84% retrofit to make SRTBOT sound nice, 00:09:38.050 --> 00:09:39.670 align:middle line:84% but I think the idea here is that you 00:09:39.670 --> 00:09:40.960 align:middle line:84% need to go back to your original problem 00:09:40.960 --> 00:09:42.335 align:middle line:84% and make sure that it corresponds 00:09:42.335 --> 00:09:44.830 align:middle line:84% to one of the function calls that you've written 00:09:44.830 --> 00:09:46.390 align:middle line:90% in all this complicated stuff. 00:09:46.390 --> 00:09:48.620 align:middle line:84% Hopefully that's a reasonable characterization. 00:09:48.620 --> 00:09:51.280 align:middle line:84% And then, finally, the t is more-- 00:09:51.280 --> 00:09:53.440 align:middle line:84% these are for describing your algorithm. 00:09:53.440 --> 00:09:55.270 align:middle line:84% The last one is for analyzing it. 00:09:55.270 --> 00:09:57.670 align:middle line:84% And, again, the BOT part of SRTBOT 00:09:57.670 --> 00:10:00.490 align:middle line:84% almost applies to anything we've done in 6.006, like you should 00:10:00.490 --> 00:10:02.780 align:middle line:90% always analyze your run time. 00:10:02.780 --> 00:10:03.280 align:middle line:90% OK. 00:10:03.280 --> 00:10:07.190 align:middle line:84% So, in any event, that's my 10-minute version 00:10:07.190 --> 00:10:10.340 align:middle line:84% of the last couple lectures and, I think, more or less, 00:10:10.340 --> 00:10:13.757 align:middle line:84% enough to get us started with some sample problems here. 00:10:13.757 --> 00:10:14.840 align:middle line:90% Sorry, I couldn't help it. 00:10:14.840 --> 00:10:16.530 align:middle line:90% I like to teach things. 00:10:16.530 --> 00:10:17.030 align:middle line:90% OK. 00:10:17.030 --> 00:10:18.320 align:middle line:90% So, right. 00:10:18.320 --> 00:10:20.570 align:middle line:84% So in our problem session, we have 00:10:20.570 --> 00:10:25.220 align:middle line:84% a few of the homework problems from last year to go over. 00:10:25.220 --> 00:10:26.900 align:middle line:84% If it makes you guys feel any better, 00:10:26.900 --> 00:10:28.648 align:middle line:84% I got myself all balled up on one of them 00:10:28.648 --> 00:10:30.440 align:middle line:84% last night while I was preparing for today. 00:10:30.440 --> 00:10:33.050 align:middle line:84% And I look forward to doing that in front of all of you guys 00:10:33.050 --> 00:10:34.470 align:middle line:90% now. 00:10:34.470 --> 00:10:34.970 align:middle line:90% Right. 00:10:34.970 --> 00:10:40.080 align:middle line:84% So, I'm afraid of this, so I'm going to go to the next board. 00:10:40.080 --> 00:10:40.580 align:middle line:90% OK. 00:10:40.580 --> 00:10:44.690 align:middle line:84% So in our first problem, Sunny studies-- 00:10:44.690 --> 00:10:46.640 align:middle line:84% this was-- somehow, the cute naming 00:10:46.640 --> 00:10:50.210 align:middle line:84% conventions we have in 6.006 got really meta in this problem, 00:10:50.210 --> 00:10:52.340 align:middle line:84% because there's a problem about Tim the Beaver. 00:10:52.340 --> 00:10:55.490 align:middle line:84% But, as we all know, Tim is MIT backwards, 00:10:55.490 --> 00:10:59.840 align:middle line:84% so he happens to fit into this goofy game 00:10:59.840 --> 00:11:02.180 align:middle line:84% that Jason likes to play in writing homework problems. 00:11:02.180 --> 00:11:05.450 align:middle line:84% Anyway, but it's also the MIT mascot. 00:11:05.450 --> 00:11:07.900 align:middle line:90% Anyway, I got very excited. 00:11:07.900 --> 00:11:08.400 align:middle line:90% Right. 00:11:08.400 --> 00:11:11.190 align:middle line:84% So what's going on in this problem? 00:11:11.190 --> 00:11:15.060 align:middle line:84% So Tim the Beaver has kind of an interesting-- you know, 00:11:15.060 --> 00:11:17.660 align:middle line:84% mathematics, I think you would call this a martingale if you 00:11:17.660 --> 00:11:19.910 align:middle line:84% flip the coin a little bit when he solve this problem. 00:11:19.910 --> 00:11:24.890 align:middle line:84% But luckily, Tim the Beaver is a deterministic kind of a guy. 00:11:24.890 --> 00:11:27.230 align:middle line:84% And he looks at the weather outside, 00:11:27.230 --> 00:11:29.570 align:middle line:84% and if it's a temperature t-- apparently, 00:11:29.570 --> 00:11:31.940 align:middle line:84% Tim the Beaver is OK with boiling. 00:11:31.940 --> 00:11:35.570 align:middle line:84% The higher the temperature, the happier Tim gets. 00:11:35.570 --> 00:11:38.630 align:middle line:84% So this is a first derivative kind of a phenomenon. 00:11:38.630 --> 00:11:45.200 align:middle line:84% In particular, on a given day, if I have a temperature t, 00:11:45.200 --> 00:11:47.720 align:middle line:84% Tim the Beaver has two things that he 00:11:47.720 --> 00:11:49.670 align:middle line:90% can do to change his mood. 00:11:49.670 --> 00:11:51.980 align:middle line:84% Apparently, Tim the Beaver's mood never stays fixed. 00:11:51.980 --> 00:11:54.800 align:middle line:90% It always goes up and down. 00:11:54.800 --> 00:12:05.430 align:middle line:84% In particular, he can either go outside, in which case 00:12:05.430 --> 00:12:21.450 align:middle line:84% the happiness increases by t, OK, or he can stay inside, 00:12:21.450 --> 00:12:29.750 align:middle line:84% in which case his happiness decreases by t. 00:12:29.750 --> 00:12:30.340 align:middle line:90% OK. 00:12:30.340 --> 00:12:35.175 align:middle line:84% So every day, Tim the Beaver, he wakes up he-- 00:12:35.175 --> 00:12:37.300 align:middle line:84% I really want to say that he checks for his shadow, 00:12:37.300 --> 00:12:39.400 align:middle line:90% but that's a gopher, right? 00:12:39.400 --> 00:12:42.910 align:middle line:84% i any event, he wakes up in the morning, he checks the weather, 00:12:42.910 --> 00:12:44.432 align:middle line:84% and he makes the determination does 00:12:44.432 --> 00:12:45.640 align:middle line:90% he want to go outside or not. 00:12:45.640 --> 00:12:47.680 align:middle line:84% And if he goes outside, he gets happier 00:12:47.680 --> 00:12:50.320 align:middle line:84% by an amount that's equal to the temperature. 00:12:50.320 --> 00:12:53.808 align:middle line:84% If he stays inside, he gets less happy by an amount that's 00:12:53.808 --> 00:12:54.850 align:middle line:90% equal to the temperature. 00:12:54.850 --> 00:12:56.933 align:middle line:84% By the way, I think our solution is perfectly fine 00:12:56.933 --> 00:13:00.040 align:middle line:84% if temperatures are negative here, in which case, 00:13:00.040 --> 00:13:02.620 align:middle line:84% I guess, everything would flip intuitively. 00:13:02.620 --> 00:13:06.400 align:middle line:84% But there's no reason to get too hung up on that. 00:13:06.400 --> 00:13:09.070 align:middle line:84% But, of course, there's a twist here. 00:13:09.070 --> 00:13:19.040 align:middle line:84% So Tim, as with many of you, has n days until his final exam. 00:13:19.040 --> 00:13:23.030 align:middle line:90% 00:13:23.030 --> 00:13:24.840 align:middle line:90% And he's worried about studying. 00:13:24.840 --> 00:13:25.340 align:middle line:90% Yeah? 00:13:25.340 --> 00:13:30.140 align:middle line:84% So, in particular, he never wants to go-- 00:13:30.140 --> 00:13:31.760 align:middle line:84% he's come up with a personal resolve 00:13:31.760 --> 00:13:35.090 align:middle line:84% to never go outside more than two days in a row. 00:13:35.090 --> 00:13:37.040 align:middle line:90% Yeah? 00:13:37.040 --> 00:13:37.940 align:middle line:90% So, right. 00:13:37.940 --> 00:13:47.590 align:middle line:90% 00:13:47.590 --> 00:13:52.117 align:middle line:84% And so the question is-- right, because that way 00:13:52.117 --> 00:13:53.950 align:middle line:84% he has to stay inside and study at least one 00:13:53.950 --> 00:13:56.030 align:middle line:90% out of every three-ish days. 00:13:56.030 --> 00:13:56.810 align:middle line:90% OK. 00:13:56.810 --> 00:14:02.490 align:middle line:84% So the question is how can Tim maximize his happiness. 00:14:02.490 --> 00:14:04.350 align:middle line:84% Incidentally, in machine learning, 00:14:04.350 --> 00:14:06.310 align:middle line:84% sometimes they call that minimizing regret, 00:14:06.310 --> 00:14:08.070 align:middle line:84% which I always found to be a very sad way 00:14:08.070 --> 00:14:11.580 align:middle line:84% to think about algorithms when there's a totally dual version. 00:14:11.580 --> 00:14:12.780 align:middle line:90% But Tim's an optimistic guy. 00:14:12.780 --> 00:14:15.180 align:middle line:84% He wants to maximize his happiness subject to this 00:14:15.180 --> 00:14:18.510 align:middle line:84% constraint that he cannot go outside more than two days 00:14:18.510 --> 00:14:19.020 align:middle line:90% in a row. 00:14:19.020 --> 00:14:19.520 align:middle line:90% Right? 00:14:19.520 --> 00:14:21.150 align:middle line:84% So if I go out on Monday and Tuesday, 00:14:21.150 --> 00:14:23.880 align:middle line:84% I have to stay inside on Wednesday. 00:14:23.880 --> 00:14:24.380 align:middle line:90% Yes? 00:14:24.380 --> 00:14:26.547 align:middle line:84% AUDIENCE: I think there's no effect to his happiness 00:14:26.547 --> 00:14:27.290 align:middle line:90% when he stays in. 00:14:27.290 --> 00:14:29.373 align:middle line:84% JUSTIN SOLOMON: There's no effect to his happiness 00:14:29.373 --> 00:14:31.750 align:middle line:90% when he stays in. 00:14:31.750 --> 00:14:34.107 align:middle line:84% AUDIENCE: At least, that's [INAUDIBLE].. 00:14:34.107 --> 00:14:36.440 align:middle line:84% JUSTIN SOLOMON: No, it says with a decrease in happiness 00:14:36.440 --> 00:14:39.998 align:middle line:90% when t-- oh, when t is negative. 00:14:39.998 --> 00:14:42.290 align:middle line:84% That's not actually going to affect our problem at all. 00:14:42.290 --> 00:14:45.687 align:middle line:90% 00:14:45.687 --> 00:14:47.270 align:middle line:84% AUDIENCE: It's not going to affect it. 00:14:47.270 --> 00:14:50.838 align:middle line:84% JUSTIN SOLOMON: Sure, yeah, I can fix this live. 00:14:50.838 --> 00:14:52.880 align:middle line:84% This is what happens when I do the problem myself 00:14:52.880 --> 00:14:56.320 align:middle line:84% before looking at the answer and then don't check it closely. 00:14:56.320 --> 00:14:56.820 align:middle line:90% Fine. 00:14:56.820 --> 00:14:59.190 align:middle line:90% So let's change that. 00:14:59.190 --> 00:15:02.010 align:middle line:84% I like this problem better, somehow, psychologically. 00:15:02.010 --> 00:15:03.450 align:middle line:90% But that's OK. 00:15:03.450 --> 00:15:03.950 align:middle line:90% Right. 00:15:03.950 --> 00:15:07.110 align:middle line:84% So, Jason correctly points out that if you actually 00:15:07.110 --> 00:15:11.940 align:middle line:84% read the problem, what's asked there is slightly different, 00:15:11.940 --> 00:15:14.610 align:middle line:84% that when he goes outside, his happiness increases by t. 00:15:14.610 --> 00:15:17.350 align:middle line:84% If he stays inside, his happiness does nothing. 00:15:17.350 --> 00:15:17.850 align:middle line:90% Right? 00:15:17.850 --> 00:15:23.530 align:middle line:90% So it stays the same. 00:15:23.530 --> 00:15:27.110 align:middle line:84% My apologies, so Tim the Beaver is a particularly optimistic 00:15:27.110 --> 00:15:27.610 align:middle line:90% beaver. 00:15:27.610 --> 00:15:30.130 align:middle line:84% His happiness can only increase in time, 00:15:30.130 --> 00:15:33.010 align:middle line:84% assuming he lives in a climate with positive temperatures. 00:15:33.010 --> 00:15:34.030 align:middle line:90% OK. 00:15:34.030 --> 00:15:35.620 align:middle line:90% I think I've got it right now. 00:15:35.620 --> 00:15:36.320 align:middle line:90% Cool. 00:15:36.320 --> 00:15:39.670 align:middle line:84% We'll see if I can still do this. 00:15:39.670 --> 00:15:42.520 align:middle line:84% Yeah, I think basically nothing changes. 00:15:42.520 --> 00:15:45.610 align:middle line:90% OK, that's great. 00:15:45.610 --> 00:15:46.110 align:middle line:90% All right. 00:15:46.110 --> 00:15:46.985 align:middle line:90% We're going to do it. 00:15:46.985 --> 00:15:51.760 align:middle line:90% 00:15:51.760 --> 00:15:52.930 align:middle line:90% OK. 00:15:52.930 --> 00:15:56.440 align:middle line:84% Right, so the question is how do we solve this problem. 00:15:56.440 --> 00:15:59.230 align:middle line:84% And thankfully, I think we put the easiest problem first. 00:15:59.230 --> 00:16:03.000 align:middle line:84% And, in particular, if we're following our SRTBOT paradigm 00:16:03.000 --> 00:16:06.480 align:middle line:84% here, somehow there's a set of subproblems that 00:16:06.480 --> 00:16:09.190 align:middle line:90% are staring us in the face. 00:16:09.190 --> 00:16:11.400 align:middle line:90% That's the word I'm looking for. 00:16:11.400 --> 00:16:15.330 align:middle line:84% In particular, well, there's sort 00:16:15.330 --> 00:16:17.160 align:middle line:84% of only one index in our problem, which 00:16:17.160 --> 00:16:18.600 align:middle line:90% is what day it is. 00:16:18.600 --> 00:16:21.150 align:middle line:84% So the obvious thing to do would be to say, 00:16:21.150 --> 00:16:23.550 align:middle line:84% can we figure out the maximum amount 00:16:23.550 --> 00:16:27.810 align:middle line:84% of happiness for days, say, i to the last day? 00:16:27.810 --> 00:16:30.240 align:middle line:84% By the way, if I do that, I'm using the prefix version 00:16:30.240 --> 00:16:31.720 align:middle line:90% of my problem-- 00:16:31.720 --> 00:16:33.700 align:middle line:84% ah, suffix version of my problem. 00:16:33.700 --> 00:16:36.270 align:middle line:84% I could also do it the opposite way and work from the end 00:16:36.270 --> 00:16:37.262 align:middle line:90% back in. 00:16:37.262 --> 00:16:38.970 align:middle line:84% Maybe if we have time all the way at end, 00:16:38.970 --> 00:16:39.970 align:middle line:90% we'll do the second one. 00:16:39.970 --> 00:16:42.240 align:middle line:90% But it doesn't really matter. 00:16:42.240 --> 00:16:42.960 align:middle line:90% OK. 00:16:42.960 --> 00:16:46.840 align:middle line:84% So, in particular, just to add a little bit of notation, 00:16:46.840 --> 00:16:56.370 align:middle line:84% let's say that t of i is equal to the temperature on day i. 00:16:56.370 --> 00:16:57.900 align:middle line:90% OK. 00:16:57.900 --> 00:17:00.600 align:middle line:84% And now we're going to make a new thing, which 00:17:00.600 --> 00:17:02.850 align:middle line:84% is going to be the actual variable we want to compute. 00:17:02.850 --> 00:17:05.670 align:middle line:84% This is going to be x to i, which, we'll write, 00:17:05.670 --> 00:17:15.869 align:middle line:84% is the maximum happiness that you can achieve if you only 00:17:15.869 --> 00:17:22.760 align:middle line:84% consider the calendar from day i to day n, I guess inclusive. 00:17:22.760 --> 00:17:24.650 align:middle line:90% OK. 00:17:24.650 --> 00:17:26.329 align:middle line:84% Incidentally, just for convenience, 00:17:26.329 --> 00:17:28.250 align:middle line:84% we'll assume that x i is equal to 0 00:17:28.250 --> 00:17:32.090 align:middle line:84% if I go past the end of my array, which I think 00:17:32.090 --> 00:17:36.730 align:middle line:84% is, kind of, a, typical thing to do in these type DP algorithms. 00:17:36.730 --> 00:17:37.330 align:middle line:90% OK. 00:17:37.330 --> 00:17:40.060 align:middle line:84% So the question is can we actually come up 00:17:40.060 --> 00:17:42.650 align:middle line:84% with a recursive algorithm that computes 00:17:42.650 --> 00:17:50.080 align:middle line:84% x i using this nice, sort of, typologically acyclic way 00:17:50.080 --> 00:17:51.820 align:middle line:90% of thinking about our problem. 00:17:51.820 --> 00:17:55.060 align:middle line:84% The answer is obviously yes, or I wouldn't be here today. 00:17:55.060 --> 00:17:58.390 align:middle line:84% And so in the absence of a smarter idea, 00:17:58.390 --> 00:18:01.720 align:middle line:84% let's just do the Toucan Sam approach here and follow 00:18:01.720 --> 00:18:06.610 align:middle line:84% our nose and see if we can just write our problem in terms 00:18:06.610 --> 00:18:08.120 align:middle line:90% of other ones. 00:18:08.120 --> 00:18:10.330 align:middle line:84% So, in general, let's say that Tim the Beaver 00:18:10.330 --> 00:18:12.160 align:middle line:90% wakes up on day i. 00:18:12.160 --> 00:18:16.030 align:middle line:84% He has, basically, two decisions that he can make, right? 00:18:16.030 --> 00:18:20.410 align:middle line:84% He can either stay inside or he can not stay inside. 00:18:20.410 --> 00:18:22.360 align:middle line:90% He can go outside, right? 00:18:22.360 --> 00:18:27.320 align:middle line:84% So let's just basically handle these three cases. 00:18:27.320 --> 00:18:30.460 align:middle line:90% So in case, one he stays inside. 00:18:30.460 --> 00:18:33.430 align:middle line:90% 00:18:33.430 --> 00:18:36.790 align:middle line:84% Well, now what happens to his happiness? 00:18:36.790 --> 00:18:39.430 align:middle line:84% Well, according to my revised version 00:18:39.430 --> 00:18:44.870 align:middle line:84% of this problem, nothing, so, in particular, what do we know? 00:18:44.870 --> 00:18:47.302 align:middle line:84% Well, if he stays inside, then he has-- 00:18:47.302 --> 00:18:49.510 align:middle line:84% any decision he can make tomorrow, it doesn't matter. 00:18:49.510 --> 00:18:51.190 align:middle line:84% He can go inside, he can go outside, 00:18:51.190 --> 00:18:53.530 align:middle line:84% whatever, because by having stayed inside, 00:18:53.530 --> 00:18:56.890 align:middle line:84% he's earned himself two free days of going outside 00:18:56.890 --> 00:18:57.810 align:middle line:90% if he wants. 00:18:57.810 --> 00:18:58.420 align:middle line:90% Right? 00:18:58.420 --> 00:19:02.500 align:middle line:84% So, in particular, in this case, we can convince ourselves 00:19:02.500 --> 00:19:08.170 align:middle line:90% that this is true, I think. 00:19:08.170 --> 00:19:12.520 align:middle line:84% Yes, so, in other words, while he gets no utility for today, 00:19:12.520 --> 00:19:14.770 align:middle line:84% he wakes up tomorrow and he can make whatever decision 00:19:14.770 --> 00:19:16.400 align:middle line:90% he wants. 00:19:16.400 --> 00:19:18.860 align:middle line:90% OK. 00:19:18.860 --> 00:19:20.900 align:middle line:84% The second thing he can do is go out. 00:19:20.900 --> 00:19:25.760 align:middle line:90% 00:19:25.760 --> 00:19:28.110 align:middle line:84% This is where things get a little tricky. 00:19:28.110 --> 00:19:28.610 align:middle line:90% Right? 00:19:28.610 --> 00:19:34.170 align:middle line:84% Can I just do, like, take t i and add it to x i plus 1? 00:19:34.170 --> 00:19:37.468 align:middle line:90% What goes wrong? 00:19:37.468 --> 00:19:38.940 align:middle line:84% AUDIENCE: You go out three days-- 00:19:38.940 --> 00:19:41.440 align:middle line:84% JUSTIN SOLOMON: Maybe you go out three days in a row, right? 00:19:41.440 --> 00:19:43.770 align:middle line:84% Somehow, you have to remember that, right? 00:19:43.770 --> 00:19:47.295 align:middle line:84% And so that's where things are a little bit of a headache, 00:19:47.295 --> 00:19:51.530 align:middle line:84% that, in particular, if I go out today and tomorrow, 00:19:51.530 --> 00:19:54.080 align:middle line:84% I can't go out the day after that. 00:19:54.080 --> 00:19:57.020 align:middle line:84% And somehow, if we just dealt with this one case 00:19:57.020 --> 00:19:59.870 align:middle line:84% as t i plus x i plus 1, we wouldn't remember that. 00:19:59.870 --> 00:20:01.890 align:middle line:90% And that's a problem. 00:20:01.890 --> 00:20:04.100 align:middle line:84% So, instead, what we can do is think of there 00:20:04.100 --> 00:20:06.470 align:middle line:90% being two subcases, right? 00:20:06.470 --> 00:20:08.900 align:middle line:84% So what we're going to assume is that not only does he 00:20:08.900 --> 00:20:12.348 align:middle line:84% go out today, but that he's free to go out tomorrow. 00:20:12.348 --> 00:20:14.390 align:middle line:84% And we're going to make that recursive assumption 00:20:14.390 --> 00:20:16.910 align:middle line:90% as we move down our array. 00:20:16.910 --> 00:20:21.860 align:middle line:84% So if we do that, well, now we have case a and case b. 00:20:21.860 --> 00:20:27.630 align:middle line:84% So in case a, he goes out today and he stays in tomorrow. 00:20:27.630 --> 00:20:28.130 align:middle line:90% Yeah. 00:20:28.130 --> 00:20:35.160 align:middle line:90% 00:20:35.160 --> 00:20:35.910 align:middle line:90% OK. 00:20:35.910 --> 00:20:38.010 align:middle line:84% So what happens in this case, well-- 00:20:38.010 --> 00:20:40.800 align:middle line:90% 00:20:40.800 --> 00:20:43.260 align:middle line:84% by the way, I'm using this kind of weird arrow notation. 00:20:43.260 --> 00:20:44.310 align:middle line:84% I don't know if this is good or not, 00:20:44.310 --> 00:20:45.450 align:middle line:84% but, essentially, the point is that I'm 00:20:45.450 --> 00:20:47.490 align:middle line:84% keeping track of cases, and then eventually I'm 00:20:47.490 --> 00:20:49.032 align:middle line:84% going to want to have to take the max 00:20:49.032 --> 00:20:50.382 align:middle line:90% overall of these things. 00:20:50.382 --> 00:20:52.590 align:middle line:84% So I don't like the equal sign because somehow that's 00:20:52.590 --> 00:20:54.750 align:middle line:90% a little misleading. 00:20:54.750 --> 00:20:55.250 align:middle line:90% Right. 00:20:55.250 --> 00:20:58.050 align:middle line:84% So in that case, well, he gets the utility 00:20:58.050 --> 00:21:01.540 align:middle line:90% of having gone out today. 00:21:01.540 --> 00:21:04.778 align:middle line:84% Tomorrow he stays in, which means 00:21:04.778 --> 00:21:07.070 align:middle line:84% that the day after tomorrow he can do whatever the heck 00:21:07.070 --> 00:21:08.360 align:middle line:90% he wants. 00:21:08.360 --> 00:21:09.260 align:middle line:90% He has free reign. 00:21:09.260 --> 00:21:15.500 align:middle line:84% So I can write that using this recursive call. 00:21:15.500 --> 00:21:16.280 align:middle line:90% OK. 00:21:16.280 --> 00:21:22.910 align:middle line:90% Similarly-- right. 00:21:22.910 --> 00:21:26.450 align:middle line:90% 00:21:26.450 --> 00:21:29.940 align:middle line:90% I'm getting the hang of this. 00:21:29.940 --> 00:21:32.330 align:middle line:84% Sorry, this is way too entertaining for me. 00:21:32.330 --> 00:21:34.260 align:middle line:84% I can play with this board all day. 00:21:34.260 --> 00:21:34.760 align:middle line:90% OK. 00:21:34.760 --> 00:21:39.665 align:middle line:84% So in case 2b, he goes out today and he goes out tomorrow. 00:21:39.665 --> 00:21:45.500 align:middle line:90% 00:21:45.500 --> 00:21:46.020 align:middle line:90% OK? 00:21:46.020 --> 00:21:46.520 align:middle line:90% So-- 00:21:46.520 --> 00:21:47.570 align:middle line:90% AUDIENCE: He's a party animal. 00:21:47.570 --> 00:21:49.070 align:middle line:84% JUSTIN SOLOMON: He's a party animal. 00:21:49.070 --> 00:21:51.500 align:middle line:84% He is an animal and he's going out a lot. 00:21:51.500 --> 00:21:53.300 align:middle line:84% Right, so in that case, what happens? 00:21:53.300 --> 00:21:55.460 align:middle line:90% Well, he gets that. 00:21:55.460 --> 00:21:59.090 align:middle line:90% He gets today's utility. 00:21:59.090 --> 00:22:01.370 align:middle line:90% He gets tomorrow's utility. 00:22:01.370 --> 00:22:04.410 align:middle line:90% 00:22:04.410 --> 00:22:06.770 align:middle line:84% The day after, he has to stay in, 00:22:06.770 --> 00:22:09.140 align:middle line:90% so we might as well skip it. 00:22:09.140 --> 00:22:14.790 align:middle line:84% And then he can do whatever he wants the day after that. 00:22:14.790 --> 00:22:16.390 align:middle line:90% OK? 00:22:16.390 --> 00:22:20.580 align:middle line:84% So if we go back, I guess, technically, we 00:22:20.580 --> 00:22:23.770 align:middle line:84% should revise our definition of x a tiny bit, 00:22:23.770 --> 00:22:25.800 align:middle line:84% that it's not the maximum of happiness-- well, 00:22:25.800 --> 00:22:27.925 align:middle line:84% we can convince ourselves that it's the same thing. 00:22:27.925 --> 00:22:30.900 align:middle line:84% But really, it's not the maximum happiness for day i through n. 00:22:30.900 --> 00:22:32.340 align:middle line:84% It's the maximum happiness for day 00:22:32.340 --> 00:22:34.890 align:middle line:84% i through n under the assumption that he has 00:22:34.890 --> 00:22:37.040 align:middle line:90% permission to go out on day i. 00:22:37.040 --> 00:22:37.540 align:middle line:90% Right? 00:22:37.540 --> 00:22:39.090 align:middle line:84% And that's really what's going on 00:22:39.090 --> 00:22:42.010 align:middle line:84% in our recursive set of calls here. 00:22:42.010 --> 00:22:42.510 align:middle line:90% OK. 00:22:42.510 --> 00:22:45.900 align:middle line:84% So does our recursion make sense here? 00:22:45.900 --> 00:22:46.860 align:middle line:90% Cool. 00:22:46.860 --> 00:22:47.940 align:middle line:90% All right. 00:22:47.940 --> 00:22:49.930 align:middle line:90% So let's see here. 00:22:49.930 --> 00:22:51.865 align:middle line:84% So if we're following our SRTBOT-- 00:22:51.865 --> 00:22:54.240 align:middle line:84% I keep reviewing papers that use the word paradigm a lot, 00:22:54.240 --> 00:22:56.110 align:middle line:90% so I feel like I should do that. 00:22:56.110 --> 00:22:57.510 align:middle line:90% So what is t? 00:22:57.510 --> 00:22:59.710 align:middle line:90% It's the topological order. 00:22:59.710 --> 00:23:08.060 align:middle line:84% Notice that x i only depends on larger i's. 00:23:08.060 --> 00:23:10.610 align:middle line:90% 00:23:10.610 --> 00:23:12.187 align:middle line:84% So in terms of our topological order, 00:23:12.187 --> 00:23:13.770 align:middle line:84% the dependence graph is really simple. 00:23:13.770 --> 00:23:17.060 align:middle line:84% It's just a line, so remember that you 00:23:17.060 --> 00:23:18.590 align:middle line:84% can think about topological order 00:23:18.590 --> 00:23:20.475 align:middle line:84% or you can think about being acyclic graph. 00:23:20.475 --> 00:23:21.350 align:middle line:90% Those are equivalent. 00:23:21.350 --> 00:23:22.790 align:middle line:90% We covered that in this course. 00:23:22.790 --> 00:23:25.820 align:middle line:84% I kind of like thinking about acyclic graphs. 00:23:25.820 --> 00:23:29.240 align:middle line:84% So x1 depends on x2 depends on x3 depends on x4. 00:23:29.240 --> 00:23:33.770 align:middle line:84% That graph has no cycles, so we're good. 00:23:33.770 --> 00:23:35.150 align:middle line:90% Right. 00:23:35.150 --> 00:23:38.090 align:middle line:84% So next we have to come up with our base 00:23:38.090 --> 00:23:40.130 align:middle line:90% case for our recursion. 00:23:40.130 --> 00:23:43.730 align:middle line:84% Notice that the way I have chosen to solve this problem 00:23:43.730 --> 00:23:47.360 align:middle line:84% is by calling future indices, which 00:23:47.360 --> 00:23:50.650 align:middle line:84% means that my base case sits at the end of my array 00:23:50.650 --> 00:23:53.150 align:middle line:84% because that's sort of like the lowest down on the recursion 00:23:53.150 --> 00:23:53.650 align:middle line:90% train. 00:23:53.650 --> 00:23:56.030 align:middle line:84% The recursion chain is what I was going for, 00:23:56.030 --> 00:23:59.120 align:middle line:84% but I kind of like the recursion train better. 00:23:59.120 --> 00:24:02.600 align:middle line:90% In particular, on day n-- 00:24:02.600 --> 00:24:06.670 align:middle line:84% well, if he has permission to go out on day n, 00:24:06.670 --> 00:24:07.970 align:middle line:90% he can do one of two things. 00:24:07.970 --> 00:24:09.137 align:middle line:90% He can either go out or not. 00:24:09.137 --> 00:24:10.780 align:middle line:90% It doesn't matter, right? 00:24:10.780 --> 00:24:16.220 align:middle line:84% So, in particular, we can say that that's the max of 0 00:24:16.220 --> 00:24:17.675 align:middle line:90% or t of n. 00:24:17.675 --> 00:24:19.550 align:middle line:84% Remember, I didn't tell you that temperatures 00:24:19.550 --> 00:24:21.770 align:middle line:90% have to be positive. 00:24:21.770 --> 00:24:24.800 align:middle line:84% Maybe he's a Celsius kind of a beaver. 00:24:24.800 --> 00:24:26.610 align:middle line:90% OK. 00:24:26.610 --> 00:24:27.110 align:middle line:90% Right. 00:24:27.110 --> 00:24:31.070 align:middle line:90% And then in addition to the-- 00:24:31.070 --> 00:24:33.053 align:middle line:84% for convenience, notice that, like, 00:24:33.053 --> 00:24:35.470 align:middle line:84% there's a universe where I look beyond the end of my array 00:24:35.470 --> 00:24:38.920 align:middle line:84% in my recursive call here, so I should probably think about 00:24:38.920 --> 00:24:40.600 align:middle line:90% a few extra x's. 00:24:40.600 --> 00:24:43.390 align:middle line:84% Obviously, the utility of going out on a day that doesn't exist 00:24:43.390 --> 00:24:44.890 align:middle line:90% is 0. 00:24:44.890 --> 00:24:52.270 align:middle line:84% So we can say that x n plus 1 equals x n plus 2 equals 0. 00:24:52.270 --> 00:24:53.440 align:middle line:90% OK. 00:24:53.440 --> 00:24:55.570 align:middle line:84% I've managed to use way too much space for one 00:24:55.570 --> 00:24:57.210 align:middle line:90% simple algorithms problem. 00:24:57.210 --> 00:25:00.770 align:middle line:90% 00:25:00.770 --> 00:25:01.270 align:middle line:90% OK. 00:25:01.270 --> 00:25:09.120 align:middle line:90% 00:25:09.120 --> 00:25:10.460 align:middle line:90% Yeah? 00:25:10.460 --> 00:25:11.410 align:middle line:90% I get credit for that? 00:25:11.410 --> 00:25:12.940 align:middle line:90% OK. 00:25:12.940 --> 00:25:13.440 align:middle line:90% Right. 00:25:13.440 --> 00:25:16.430 align:middle line:84% So now we need to do the o and the t. 00:25:16.430 --> 00:25:20.280 align:middle line:90% So what's our original problem? 00:25:20.280 --> 00:25:22.950 align:middle line:84% Well, remember that he wants to maximize his happiness starting 00:25:22.950 --> 00:25:32.510 align:middle line:84% on day one, so our original problem is just x of 1, 00:25:32.510 --> 00:25:33.680 align:middle line:90% or is it? 00:25:33.680 --> 00:25:36.140 align:middle line:84% So, remember that Tim the Beaver-- 00:25:36.140 --> 00:25:37.640 align:middle line:84% your instructor is very sloppy when 00:25:37.640 --> 00:25:39.390 align:middle line:84% it comes to actually reading the problems, 00:25:39.390 --> 00:25:41.630 align:middle line:90% as you saw at the beginning. 00:25:41.630 --> 00:25:43.940 align:middle line:84% A second mistake for which I would have personally 00:25:43.940 --> 00:25:46.730 align:middle line:84% lost points were I to solve this problem on my homework 00:25:46.730 --> 00:25:50.540 align:middle line:84% is that it didn't ask for just the maximum amount of happiness 00:25:50.540 --> 00:25:52.370 align:middle line:90% that Tim could achieve-- 00:25:52.370 --> 00:25:55.520 align:middle line:84% that's not very practical for your everyday beaver-- 00:25:55.520 --> 00:25:57.945 align:middle line:84% but rather, he wants to know the actual plan. 00:25:57.945 --> 00:26:00.320 align:middle line:84% He wants to know what days he can go out and what days he 00:26:00.320 --> 00:26:00.890 align:middle line:90% can't. 00:26:00.890 --> 00:26:01.460 align:middle line:90% Yeah? 00:26:01.460 --> 00:26:03.710 align:middle line:84% And I haven't actually told you how to do that, right? 00:26:03.710 --> 00:26:05.085 align:middle line:84% I've only told you how to compute 00:26:05.085 --> 00:26:09.660 align:middle line:84% x, which is just the maximum amount of happiness. 00:26:09.660 --> 00:26:11.340 align:middle line:84% If I were you guys, I think this is 00:26:11.340 --> 00:26:13.317 align:middle line:84% a perfectly reasonable simplification that's 00:26:13.317 --> 00:26:14.650 align:middle line:90% like a warm up problem to solve. 00:26:14.650 --> 00:26:17.220 align:middle line:84% In fact, I would argue it's less of a warm up and more 00:26:17.220 --> 00:26:18.642 align:middle line:90% the crux of the problem-- 00:26:18.642 --> 00:26:20.100 align:middle line:84% and then going back and making sure 00:26:20.100 --> 00:26:22.142 align:middle line:84% you can convince yourself that you could actually 00:26:22.142 --> 00:26:24.960 align:middle line:90% reconstruct the solution. 00:26:24.960 --> 00:26:27.067 align:middle line:84% My way of solving this was ever so slightly 00:26:27.067 --> 00:26:28.650 align:middle line:84% different from the one in the problem, 00:26:28.650 --> 00:26:31.740 align:middle line:84% but they're equivalent, which is to say 00:26:31.740 --> 00:26:33.332 align:middle line:90% I can make a second array-- 00:26:33.332 --> 00:26:36.050 align:middle line:84% I won't write it down, because I'm slow at writing-- 00:26:36.050 --> 00:26:39.110 align:middle line:84% that just says on every day, whether I took option 1, option 00:26:39.110 --> 00:26:41.712 align:middle line:90% 2a, or option 2b. 00:26:41.712 --> 00:26:43.920 align:middle line:84% And now I can reconstruct my plan very easily, right? 00:26:43.920 --> 00:26:48.330 align:middle line:84% So I look at x1, if I took option 1, then I stay in 00:26:48.330 --> 00:26:50.580 align:middle line:90% and I look at day two. 00:26:50.580 --> 00:26:55.870 align:middle line:84% If I took option 2a, then I can label today, tomorrow, 00:26:55.870 --> 00:26:56.720 align:middle line:90% and the day after. 00:26:56.720 --> 00:26:59.910 align:middle line:90% Oh, wait-- yeah, that's right. 00:26:59.910 --> 00:27:02.400 align:middle line:84% I can label today's choice, tomorrow's choice, the day's 00:27:02.400 --> 00:27:05.460 align:middle line:84% after choice, and then look three days later 00:27:05.460 --> 00:27:07.500 align:middle line:90% and recurse that way. 00:27:07.500 --> 00:27:10.260 align:middle line:90% Option b is kind of similar. 00:27:10.260 --> 00:27:13.432 align:middle line:84% So a reasonable way to reconstruct the actual set 00:27:13.432 --> 00:27:15.390 align:middle line:84% of what days you go out and what days you go in 00:27:15.390 --> 00:27:19.950 align:middle line:84% is just to remember, as you do your memoization or whatever, 00:27:19.950 --> 00:27:22.140 align:middle line:84% whether you did option 1, 2a, or 2b. 00:27:22.140 --> 00:27:24.420 align:middle line:84% And then it's pretty easy to reconstruct from there. 00:27:24.420 --> 00:27:26.212 align:middle line:84% Maybe I'll let you guys convince yourselves 00:27:26.212 --> 00:27:28.290 align:middle line:84% of that at home or in the last 8 seconds 00:27:28.290 --> 00:27:31.530 align:middle line:84% if you happen to be the two audience members that I have. 00:27:31.530 --> 00:27:36.760 align:middle line:84% And then, finally, we need to do our time thing. 00:27:36.760 --> 00:27:38.478 align:middle line:84% And most of the time arguments here 00:27:38.478 --> 00:27:40.020 align:middle line:84% follow more or less the same pattern, 00:27:40.020 --> 00:27:41.610 align:middle line:84% which is you count the number of subproblems 00:27:41.610 --> 00:27:44.027 align:middle line:84% and the time per subproblem, you multiply those two things 00:27:44.027 --> 00:27:45.935 align:middle line:84% together, and you get your runtime. 00:27:45.935 --> 00:27:47.310 align:middle line:84% We're going to see in one problem 00:27:47.310 --> 00:27:49.920 align:middle line:84% on this problem set that's not quite right because we 00:27:49.920 --> 00:27:52.260 align:middle line:84% have to account for some precomputation. 00:27:52.260 --> 00:27:53.910 align:middle line:90% But in this case, it is. 00:27:53.910 --> 00:27:57.220 align:middle line:90% 00:27:57.220 --> 00:27:59.752 align:middle line:84% Right, so let's see, what are our subproblems here? 00:27:59.752 --> 00:28:01.960 align:middle line:84% Well, essentially-- I guess I didn't actually say it, 00:28:01.960 --> 00:28:06.210 align:middle line:84% but you have to take the max of these three values. 00:28:06.210 --> 00:28:08.130 align:middle line:84% This is the max of three expressions which 00:28:08.130 --> 00:28:10.380 align:middle line:84% have a constant number of plus signs and lookups 00:28:10.380 --> 00:28:12.610 align:middle line:84% and memory and all that good stuff. 00:28:12.610 --> 00:28:21.310 align:middle line:84% So each subproblem takes order one time. 00:28:21.310 --> 00:28:23.300 align:middle line:90% How many problems are there? 00:28:23.300 --> 00:28:26.830 align:middle line:84% Well, there's, I guess, n plus 2 max, 00:28:26.830 --> 00:28:29.080 align:middle line:84% if you want to be conservative about it. 00:28:29.080 --> 00:28:34.750 align:middle line:84% So, in particular, there's order n subproblems, right? 00:28:34.750 --> 00:28:37.210 align:middle line:84% So all I have to do is multiply these two things together, 00:28:37.210 --> 00:28:40.880 align:middle line:84% and my algorithm takes order n time. 00:28:40.880 --> 00:28:43.610 align:middle line:90% 00:28:43.610 --> 00:28:47.730 align:middle line:84% And that's our solution to problem number one. 00:28:47.730 --> 00:28:49.620 align:middle line:90% Any questions so far? 00:28:49.620 --> 00:28:50.120 align:middle line:90% Yes? 00:28:50.120 --> 00:28:51.552 align:middle line:90% Uh-oh. 00:28:51.552 --> 00:28:54.010 align:middle line:84% AUDIENCE: When I was thinking about the problem beforehand, 00:28:54.010 --> 00:28:57.450 align:middle line:84% I was wondering could you use base cases-- 00:28:57.450 --> 00:29:00.590 align:middle line:84% right now, we have two different kinds of base case, 00:29:00.590 --> 00:29:05.130 align:middle line:84% a base case for x of n and a base case for things after. 00:29:05.130 --> 00:29:08.280 align:middle line:84% Can I remove the first one and add an x of n 00:29:08.280 --> 00:29:10.740 align:middle line:90% plus 3 equals 0 as well? 00:29:10.740 --> 00:29:11.997 align:middle line:90% What would that do? 00:29:11.997 --> 00:29:13.830 align:middle line:84% JUSTIN SOLOMON: Could I remove the first one 00:29:13.830 --> 00:29:16.930 align:middle line:90% and add an x of n plus 3? 00:29:16.930 --> 00:29:19.960 align:middle line:90% Yeah, I guess that's fine. 00:29:19.960 --> 00:29:22.270 align:middle line:84% I'm sorry, that's not a particularly helpful answer 00:29:22.270 --> 00:29:24.340 align:middle line:84% for the people watching on video. 00:29:24.340 --> 00:29:28.150 align:middle line:84% My answer to this question you can't hear is yes. 00:29:28.150 --> 00:29:33.550 align:middle line:84% So the question, to repeat, was this base case was somehow 00:29:33.550 --> 00:29:35.350 align:middle line:90% kind of complicated-looking. 00:29:35.350 --> 00:29:36.970 align:middle line:84% To be fair, it's the one that I was 00:29:36.970 --> 00:29:40.420 align:middle line:84% given in [INAUDIBLE] assignment, but that's OK. 00:29:40.420 --> 00:29:43.540 align:middle line:84% But the question was is this truly necessary. 00:29:43.540 --> 00:29:46.270 align:middle line:84% In particular, can I get rid of the x n case 00:29:46.270 --> 00:29:50.690 align:middle line:84% and instead add a third day past the end of time, 00:29:50.690 --> 00:29:52.600 align:middle line:90% which also has value 0? 00:29:52.600 --> 00:29:59.640 align:middle line:84% And if you, kind of, look at that plus case b, I think-- 00:29:59.640 --> 00:30:00.807 align:middle line:90% or rather, case a-- 00:30:00.807 --> 00:30:02.640 align:middle line:84% think you can convince-- well, case a and b, 00:30:02.640 --> 00:30:04.973 align:middle line:84% for that matter-- you can convince yourselves that these 00:30:04.973 --> 00:30:05.970 align:middle line:90% are equivalent, right? 00:30:05.970 --> 00:30:06.970 align:middle line:90% That's absolutely right. 00:30:06.970 --> 00:30:11.100 align:middle line:84% So I could add a third day after the end of this thing, which 00:30:11.100 --> 00:30:12.570 align:middle line:90% also has value 0. 00:30:12.570 --> 00:30:16.260 align:middle line:84% Or, by the way, I could just say in my code if n is-- 00:30:16.260 --> 00:30:18.390 align:middle line:90% if i is bigger than n, return 0. 00:30:18.390 --> 00:30:21.472 align:middle line:90% That's the same thing. 00:30:21.472 --> 00:30:22.930 align:middle line:84% Yeah, and then I guess I don't have 00:30:22.930 --> 00:30:24.360 align:middle line:90% to worry about that x n case. 00:30:24.360 --> 00:30:26.610 align:middle line:90% Yeah, these are the same. 00:30:26.610 --> 00:30:28.740 align:middle line:90% To each their own. 00:30:28.740 --> 00:30:29.620 align:middle line:90% Fabulous question. 00:30:29.620 --> 00:30:34.030 align:middle line:84% Any others that I can answer while we're at it? 00:30:34.030 --> 00:30:35.010 align:middle line:90% Cool. 00:30:35.010 --> 00:30:35.510 align:middle line:90% All right. 00:30:35.510 --> 00:30:36.427 align:middle line:90% So that's problem one. 00:30:36.427 --> 00:30:39.016 align:middle line:90% 00:30:39.016 --> 00:30:41.980 align:middle line:84% Writing too big-- I don't like this big chalk, you know. 00:30:41.980 --> 00:30:42.480 align:middle line:90% OK. 00:30:42.480 --> 00:30:44.362 align:middle line:84% So problem two is the one that got me all hot 00:30:44.362 --> 00:30:45.320 align:middle line:90% and bothered yesterday. 00:30:45.320 --> 00:30:47.880 align:middle line:84% So let's see if we do any better in front of people, 00:30:47.880 --> 00:30:50.010 align:middle line:84% because that's usually the best way to improve 00:30:50.010 --> 00:30:52.230 align:middle line:90% a problem solving skill. 00:30:52.230 --> 00:30:53.280 align:middle line:90% Right. 00:30:53.280 --> 00:30:56.430 align:middle line:84% So in problem two, which, annoyingly, 00:30:56.430 --> 00:30:58.860 align:middle line:84% is also probably the most practical problem 00:30:58.860 --> 00:31:00.240 align:middle line:90% on this problem set. 00:31:00.240 --> 00:31:02.162 align:middle line:90% Essentially, you have a-- 00:31:02.162 --> 00:31:03.870 align:middle line:84% I suppose I should write some stuff down. 00:31:03.870 --> 00:31:06.450 align:middle line:90% 00:31:06.450 --> 00:31:07.770 align:middle line:90% So in problem-- 00:31:07.770 --> 00:31:10.410 align:middle line:90% I used the wrong side-- 00:31:10.410 --> 00:31:16.090 align:middle line:84% two, you have an operating system Menix-- 00:31:16.090 --> 00:31:19.864 align:middle line:90% whatever-- which is-- 00:31:19.864 --> 00:31:21.442 align:middle line:90% apparently, it's very simple. 00:31:21.442 --> 00:31:23.170 align:middle line:90% AUDIENCE: Menix, Unix. 00:31:23.170 --> 00:31:24.478 align:middle line:90% JUSTIN SOLOMON: Oh, I get it. 00:31:24.478 --> 00:31:27.950 align:middle line:84% [LAUGHS] It doesn't mean I have to like it. 00:31:27.950 --> 00:31:28.450 align:middle line:90% Right. 00:31:28.450 --> 00:31:35.830 align:middle line:84% [LAUGHS] So, in Menix, apparently, 00:31:35.830 --> 00:31:37.840 align:middle line:84% the only thing that my operating system can do 00:31:37.840 --> 00:31:41.590 align:middle line:84% is compute edit distance between files. 00:31:41.590 --> 00:31:43.730 align:middle line:84% And it wants to do so efficiently. 00:31:43.730 --> 00:31:50.315 align:middle line:84% So we have that a file is a sequence of strings. 00:31:50.315 --> 00:31:54.940 align:middle line:90% 00:31:54.940 --> 00:31:57.840 align:middle line:84% And I believe we say their length is 00:31:57.840 --> 00:31:59.310 align:middle line:90% less than or equal to k. 00:31:59.310 --> 00:32:02.940 align:middle line:84% That's going to come into play a little bit later. 00:32:02.940 --> 00:32:05.100 align:middle line:84% And the strings are basically just lines 00:32:05.100 --> 00:32:08.020 align:middle line:90% of the different files. 00:32:08.020 --> 00:32:13.103 align:middle line:84% So there's three different ways that we can change a file. 00:32:13.103 --> 00:32:14.520 align:middle line:84% So here are the changes we can do. 00:32:14.520 --> 00:32:18.030 align:middle line:90% 00:32:18.030 --> 00:32:20.760 align:middle line:84% Change number 1 is to add a line. 00:32:20.760 --> 00:32:23.390 align:middle line:90% 00:32:23.390 --> 00:32:26.780 align:middle line:84% Change number 2 is to remove a line. 00:32:26.780 --> 00:32:29.730 align:middle line:90% 00:32:29.730 --> 00:32:34.590 align:middle line:90% And change number 3 is to swap. 00:32:34.590 --> 00:32:40.170 align:middle line:84% But a caveat for this interesting model 00:32:40.170 --> 00:32:45.390 align:middle line:84% of what's cheap and what's not is that, apparently, 00:32:45.390 --> 00:32:48.150 align:middle line:84% swapping two lines is cheap because they exist in memory. 00:32:48.150 --> 00:32:50.910 align:middle line:84% Like, maybe I'm, I don't know, using a linked 00:32:50.910 --> 00:32:53.160 align:middle line:84% list or something to store files, 00:32:53.160 --> 00:32:56.520 align:middle line:84% and so swapping two pointers isn't so bad. 00:32:56.520 --> 00:32:58.320 align:middle line:84% But inserting and removing a line 00:32:58.320 --> 00:33:01.140 align:middle line:84% is hard because, I don't know, memory allocation is expensive, 00:33:01.140 --> 00:33:04.740 align:middle line:84% like Menix is actually operating on clay tablets. 00:33:04.740 --> 00:33:08.940 align:middle line:84% And I can chop my clay tablets into different slices 00:33:08.940 --> 00:33:11.880 align:middle line:84% and just pick them up and swap them, and that's fine, 00:33:11.880 --> 00:33:13.530 align:middle line:84% but if I want to add a line in my file, 00:33:13.530 --> 00:33:17.810 align:middle line:84% I have to go to the Tigris and Euphrates and pull out the-- 00:33:17.810 --> 00:33:20.280 align:middle line:84% or whatever it was, the Eugris and the 00:33:20.280 --> 00:33:23.660 align:middle line:84% Tiphrates-- and pull out a stone. 00:33:23.660 --> 00:33:27.960 align:middle line:84% It's a lot of work to make a new line or to dispose. 00:33:27.960 --> 00:33:35.680 align:middle line:84% So these are expensive and this is cheap. 00:33:35.680 --> 00:33:38.920 align:middle line:84% And so the question that I'm trying to sa-- 00:33:38.920 --> 00:33:41.890 align:middle line:84% that I'm trying to say and that the problem is trying to ask 00:33:41.890 --> 00:33:52.800 align:middle line:84% is that you are given files A and B with n lines each. 00:33:52.800 --> 00:33:57.680 align:middle line:90% 00:33:57.680 --> 00:34:03.710 align:middle line:84% We want to know what the minimum number of non-swap operations 00:34:03.710 --> 00:34:05.890 align:middle line:84% it'll take, and so, in other words, 00:34:05.890 --> 00:34:08.780 align:middle line:84% the minimum number of time for you to add and remove lines 00:34:08.780 --> 00:34:20.300 align:middle line:84% to transform A into B, essentially, with low cost. 00:34:20.300 --> 00:34:23.040 align:middle line:90% 00:34:23.040 --> 00:34:25.920 align:middle line:90% And, in fact, just to be nice-- 00:34:25.920 --> 00:34:29.460 align:middle line:84% I think it's actually kind of a critical hint in this problem-- 00:34:29.460 --> 00:34:32.190 align:middle line:90% we give you the runtime. 00:34:32.190 --> 00:34:34.273 align:middle line:84% And I'm going to, kind of, ignore it in my answer, 00:34:34.273 --> 00:34:36.398 align:middle line:84% notice that I did something wrong, and then go back 00:34:36.398 --> 00:34:36.969 align:middle line:90% and fix it. 00:34:36.969 --> 00:34:38.400 align:middle line:84% This is different from the way the answer is written, 00:34:38.400 --> 00:34:41.463 align:middle line:84% where god came in and said, like, oh, we observe that we're 00:34:41.463 --> 00:34:42.880 align:middle line:84% probably going to need this thing, 00:34:42.880 --> 00:34:44.520 align:middle line:84% so we're going to go ahead and do it here. 00:34:44.520 --> 00:34:46.770 align:middle line:84% I think that's, maybe, not representative of the logic 00:34:46.770 --> 00:34:48.150 align:middle line:90% here. 00:34:48.150 --> 00:34:53.250 align:middle line:84% Right, so the runtime here is k n plus n squared. 00:34:53.250 --> 00:34:57.330 align:middle line:84% The first thing to note is there is a k here. 00:34:57.330 --> 00:35:02.480 align:middle line:84% Yeah, and so someday we're going to have to compare strings, 00:35:02.480 --> 00:35:03.980 align:middle line:90% because that's what k is. 00:35:03.980 --> 00:35:05.408 align:middle line:84% And I think that's the hint that's 00:35:05.408 --> 00:35:06.450 align:middle line:90% implicit in this problem. 00:35:06.450 --> 00:35:07.940 align:middle line:90% It's easy to miss. 00:35:07.940 --> 00:35:10.280 align:middle line:84% And so, indeed, what we're going to notice 00:35:10.280 --> 00:35:11.863 align:middle line:84% is we're going to look at our solution 00:35:11.863 --> 00:35:14.720 align:middle line:84% and say, well, wait a second, if we didn't incur a factor of k, 00:35:14.720 --> 00:35:16.850 align:middle line:84% we must have done something wrong. 00:35:16.850 --> 00:35:18.890 align:middle line:84% And, indeed, that's going to be the case, 00:35:18.890 --> 00:35:23.942 align:middle line:84% but it's only a minor fix to change it. 00:35:23.942 --> 00:35:25.900 align:middle line:84% AUDIENCE: There's another important distinction 00:35:25.900 --> 00:35:26.850 align:middle line:90% on this [INAUDIBLE]. 00:35:26.850 --> 00:35:28.100 align:middle line:90% JUSTIN SOLOMON: Oh, I'm sorry. 00:35:28.100 --> 00:35:35.006 align:middle line:84% Yeah, right, when I swap things, they have to be adjacent. 00:35:35.006 --> 00:35:38.570 align:middle line:84% I can't write at the bottom of the board. 00:35:38.570 --> 00:35:41.893 align:middle line:84% That's supposed to be a, d, j, for those watching at home. 00:35:41.893 --> 00:35:43.310 align:middle line:84% But they have to be-- you can only 00:35:43.310 --> 00:35:45.800 align:middle line:84% swap lines that are adjacent, as they 00:35:45.800 --> 00:35:47.668 align:middle line:90% appear in their original file. 00:35:47.668 --> 00:35:50.210 align:middle line:84% I'll say it out loud rather than try and write it because you 00:35:50.210 --> 00:35:52.460 align:middle line:84% it's going to take the rest of the lecture to do that. 00:35:52.460 --> 00:35:56.237 align:middle line:84% OK, any other things I've forgotten? 00:35:56.237 --> 00:35:57.320 align:middle line:90% There's a high likelihood. 00:35:57.320 --> 00:35:58.970 align:middle line:90% I'm bad at this. 00:35:58.970 --> 00:35:59.510 align:middle line:90% OK. 00:35:59.510 --> 00:36:02.870 align:middle line:90% So this one was annoying. 00:36:02.870 --> 00:36:04.650 align:middle line:90% And it's not actually annoying. 00:36:04.650 --> 00:36:07.730 align:middle line:84% It's actually a relatively easy instance of a very well-known 00:36:07.730 --> 00:36:11.780 align:middle line:84% dynamic program plus a tiny bit of additional stuff, which 00:36:11.780 --> 00:36:13.660 align:middle line:90% is called edit distance. 00:36:13.660 --> 00:36:15.910 align:middle line:84% In fact, I think if you guys are looking for intuition 00:36:15.910 --> 00:36:18.380 align:middle line:84% on this problem, you might google 00:36:18.380 --> 00:36:21.847 align:middle line:90% that one first as, sort of, a-- 00:36:21.847 --> 00:36:22.430 align:middle line:90% what was that? 00:36:22.430 --> 00:36:23.120 align:middle line:90% AUDIENCE: [INAUDIBLE] 00:36:23.120 --> 00:36:24.320 align:middle line:84% JUSTIN SOLOMON: Oh, in fact you're doing a recitation. 00:36:24.320 --> 00:36:26.690 align:middle line:84% Oh, that's why it's not totally unreasonable to come 00:36:26.690 --> 00:36:29.185 align:middle line:84% up with the answer here, even better. 00:36:29.185 --> 00:36:30.560 align:middle line:84% But even if you hadn't, you know, 00:36:30.560 --> 00:36:32.820 align:middle line:84% this is just another dynamic programming problem 00:36:32.820 --> 00:36:35.450 align:middle line:84% that's just a little bit more annoying 00:36:35.450 --> 00:36:38.720 align:middle line:84% than your average dynamic programming problem. 00:36:38.720 --> 00:36:41.180 align:middle line:84% Now, the solution written out in the course notes 00:36:41.180 --> 00:36:44.480 align:middle line:84% works from, sort of, the last line of the file 00:36:44.480 --> 00:36:47.210 align:middle line:90% downward, in some sense-- 00:36:47.210 --> 00:36:51.230 align:middle line:90% upward, whatever. 00:36:51.230 --> 00:36:53.240 align:middle line:84% I, like, literally lost two hours of my life 00:36:53.240 --> 00:36:56.330 align:middle line:84% trying to think about editing files from the end up 00:36:56.330 --> 00:36:58.768 align:middle line:84% and just getting myself all upset and confused. 00:36:58.768 --> 00:37:01.310 align:middle line:84% So here, I'm going to attempt to do it in the other direction 00:37:01.310 --> 00:37:04.170 align:middle line:84% and probably introduce a bunch of mistakes in the process. 00:37:04.170 --> 00:37:06.975 align:middle line:84% So what do we do in dynamic programming 00:37:06.975 --> 00:37:08.350 align:middle line:84% if we don't know what else to do? 00:37:08.350 --> 00:37:12.040 align:middle line:90% We do sort stuff, SRTBOT. 00:37:12.040 --> 00:37:13.910 align:middle line:90% And so let's do that here. 00:37:13.910 --> 00:37:17.110 align:middle line:84% So, in particular, what are our subproblems? 00:37:17.110 --> 00:37:19.902 align:middle line:90% This is a little bit funky. 00:37:19.902 --> 00:37:21.860 align:middle line:84% So actually, even before we do the S of SRTBOT, 00:37:21.860 --> 00:37:23.652 align:middle line:84% let's think about our problem a little bit. 00:37:23.652 --> 00:37:26.000 align:middle line:90% 00:37:26.000 --> 00:37:27.920 align:middle line:84% Let's think about what it actually 00:37:27.920 --> 00:37:30.380 align:middle line:84% means to edit a file because this 00:37:30.380 --> 00:37:33.500 align:middle line:84% is what helped me think about the right answer 00:37:33.500 --> 00:37:35.558 align:middle line:84% here, which is to say, you know-- 00:37:35.558 --> 00:37:36.350 align:middle line:90% so what's going on? 00:37:36.350 --> 00:37:38.570 align:middle line:90% I have, like, two documents. 00:37:38.570 --> 00:37:43.370 align:middle line:84% This is document A. This is document B. Each one of them 00:37:43.370 --> 00:37:46.130 align:middle line:90% is composed of a bunch of lines. 00:37:46.130 --> 00:37:47.930 align:middle line:84% And I'm basically trying to turn A into B. 00:37:47.930 --> 00:37:51.260 align:middle line:84% And the only thing I can do is scroll out of line, 00:37:51.260 --> 00:37:54.110 align:middle line:84% insert, just hit the Enter key, or do a third thing 00:37:54.110 --> 00:37:56.423 align:middle line:84% where I kind of like swap two things that 00:37:56.423 --> 00:37:57.590 align:middle line:90% are adjacent to one another. 00:37:57.590 --> 00:37:59.980 align:middle line:90% That is the only thing I can do. 00:37:59.980 --> 00:38:03.553 align:middle line:84% And the way I like to think about this problem-- 00:38:03.553 --> 00:38:04.970 align:middle line:84% there's kind of an annoyance here, 00:38:04.970 --> 00:38:06.550 align:middle line:84% which I think is a typical annoyance 00:38:06.550 --> 00:38:08.133 align:middle line:84% in dynamic programming problems, which 00:38:08.133 --> 00:38:12.900 align:middle line:84% is that the order of operations suggests that this problem is 00:38:12.900 --> 00:38:16.050 align:middle line:84% a lot, combinatorially, more difficult than it is, because, 00:38:16.050 --> 00:38:16.832 align:middle line:90% like-- 00:38:16.832 --> 00:38:19.290 align:middle line:84% OK, let's think about how I actually edit documents-- like, 00:38:19.290 --> 00:38:22.080 align:middle line:84% I spend 2/3 of my day editing bad grad student writing-- 00:38:22.080 --> 00:38:24.900 align:middle line:84% is like I'm jumping all over the place between different lines. 00:38:24.900 --> 00:38:26.460 align:middle line:84% Like, first I delete this line, then 00:38:26.460 --> 00:38:28.085 align:middle line:84% maybe I go to the bottom of my document 00:38:28.085 --> 00:38:29.220 align:middle line:90% and delete some other one. 00:38:29.220 --> 00:38:32.430 align:middle line:84% That would be a big problem from a dynamic programming 00:38:32.430 --> 00:38:33.120 align:middle line:90% perspective. 00:38:33.120 --> 00:38:35.070 align:middle line:84% I can't jump all over my document, 00:38:35.070 --> 00:38:37.950 align:middle line:84% because keeping track of that whole edit history 00:38:37.950 --> 00:38:41.620 align:middle line:84% is going to be somehow combinatorially ginormous. 00:38:41.620 --> 00:38:42.120 align:middle line:90% Right? 00:38:42.120 --> 00:38:45.120 align:middle line:84% I'm not the Track Changes button in Microsoft Word. 00:38:45.120 --> 00:38:47.910 align:middle line:84% I want the minimum number of changes. 00:38:47.910 --> 00:38:51.030 align:middle line:84% And if I have to recurse over all possible edits 00:38:51.030 --> 00:38:53.070 align:middle line:84% to every single line in any order, 00:38:53.070 --> 00:38:54.750 align:middle line:84% that's an awful lot of factorials 00:38:54.750 --> 00:38:57.240 align:middle line:84% and 2 to the n's floating around that I don't want to have. 00:38:57.240 --> 00:38:57.740 align:middle line:90% Right? 00:38:57.740 --> 00:39:01.320 align:middle line:84% And so that's the sort of crux of the challenge here, 00:39:01.320 --> 00:39:05.670 align:middle line:84% is to organize my approach to editing these files 00:39:05.670 --> 00:39:07.890 align:middle line:84% in a way that doesn't require me to have 00:39:07.890 --> 00:39:11.088 align:middle line:84% to do this sort of combinatorial jumping all over the place. 00:39:11.088 --> 00:39:13.380 align:middle line:84% And I think it's also the one where there's a sort of-- 00:39:13.380 --> 00:39:15.088 align:middle line:84% like I know Jerry Caine at Stanford talks 00:39:15.088 --> 00:39:18.480 align:middle line:84% a lot about the recursive leap of faith. 00:39:18.480 --> 00:39:20.370 align:middle line:84% Like, somehow dividing your problem 00:39:20.370 --> 00:39:22.290 align:middle line:84% into organized subproblems, that's 00:39:22.290 --> 00:39:25.690 align:middle line:84% really where the challenge lives here. 00:39:25.690 --> 00:39:28.990 align:middle line:84% So if I were a more organized PhD advisor, 00:39:28.990 --> 00:39:33.990 align:middle line:84% the way that I would edit a file, or a clay tablet, 00:39:33.990 --> 00:39:37.540 align:middle line:84% I guess, in this case, would be linearly, 00:39:37.540 --> 00:39:39.480 align:middle line:84% that I might as well do whatever the heck 00:39:39.480 --> 00:39:42.960 align:middle line:84% I'm going to do to line one before I move on the line two. 00:39:42.960 --> 00:39:45.202 align:middle line:84% And at the end of the day, even if I did stuff 00:39:45.202 --> 00:39:47.160 align:middle line:84% in a different order, you can convince yourself 00:39:47.160 --> 00:39:48.630 align:middle line:84% that I could always order it in such a way 00:39:48.630 --> 00:39:50.588 align:middle line:84% that all the edits that I do to the first line, 00:39:50.588 --> 00:39:54.920 align:middle line:84% kind of, happen before lines later in the document, 00:39:54.920 --> 00:39:57.980 align:middle line:84% with the possible exception of this swap thing. 00:39:57.980 --> 00:40:00.440 align:middle line:84% But we'll see that somehow doesn't matter. 00:40:00.440 --> 00:40:03.730 align:middle line:84% And, moreover, if I do an edit, I 00:40:03.730 --> 00:40:07.300 align:middle line:84% might as well do the edit to make things better, right? 00:40:07.300 --> 00:40:09.640 align:middle line:84% There's no reason to start willy-nilly inserting 00:40:09.640 --> 00:40:11.680 align:middle line:90% and removing lines. 00:40:11.680 --> 00:40:15.890 align:middle line:84% I might as well always do an operation that improves stuff. 00:40:15.890 --> 00:40:19.656 align:middle line:84% And so thinking about that sort of logic leads me-- 00:40:19.656 --> 00:40:23.260 align:middle line:84% ta-da-- to a particular way that I might write down 00:40:23.260 --> 00:40:26.262 align:middle line:84% my S, my some problems here, which 00:40:26.262 --> 00:40:28.720 align:middle line:84% is to say that I'm going to think about editing my document 00:40:28.720 --> 00:40:31.000 align:middle line:90% line by line. 00:40:31.000 --> 00:40:33.810 align:middle line:84% So, in other words, once I've dealt with line one, 00:40:33.810 --> 00:40:36.330 align:middle line:84% meaning that I found some way to mess with it 00:40:36.330 --> 00:40:39.170 align:middle line:84% and make it match line one of the other guy, 00:40:39.170 --> 00:40:41.570 align:middle line:84% I'm just going to think about removing it 00:40:41.570 --> 00:40:44.190 align:middle line:84% and then think about the rest of the document. 00:40:44.190 --> 00:40:47.210 align:middle line:84% You start saying, aha, that sentence sounds like recursion. 00:40:47.210 --> 00:40:47.930 align:middle line:90% And that's right. 00:40:47.930 --> 00:40:49.620 align:middle line:84% That's how we're going to solve this problem. 00:40:49.620 --> 00:40:50.180 align:middle line:90% OK? 00:40:50.180 --> 00:40:53.033 align:middle line:84% So, in particular, here's going to be our thing. 00:40:53.033 --> 00:40:55.450 align:middle line:84% I'm going to do a slightly different one in the solution-- 00:40:55.450 --> 00:40:57.830 align:middle line:84% so you guys should all be vigilant-- 00:40:57.830 --> 00:41:06.470 align:middle line:84% which is I'm going to write x ij to be the min work to convert. 00:41:06.470 --> 00:41:11.000 align:middle line:90% 00:41:11.000 --> 00:41:15.560 align:middle line:84% I'm not a Python programmer, but hopefully I got this right. 00:41:15.560 --> 00:41:18.710 align:middle line:84% i colon is going to be everything from i 00:41:18.710 --> 00:41:20.730 align:middle line:90% to the end of the file. 00:41:20.730 --> 00:41:26.310 align:middle line:84% So in other words, this is the suffix version of our problem-- 00:41:26.310 --> 00:41:36.600 align:middle line:90% and into B j colon, like that. 00:41:36.600 --> 00:41:37.680 align:middle line:90% OK. 00:41:37.680 --> 00:41:39.780 align:middle line:84% So, in other words, I have a little-- 00:41:39.780 --> 00:41:42.570 align:middle line:84% it's kind of like a video-- like, think about Tetris. 00:41:42.570 --> 00:41:44.288 align:middle line:84% Once you get that full line of blocks, 00:41:44.288 --> 00:41:46.080 align:middle line:84% you can just throw that line of blocks away 00:41:46.080 --> 00:41:47.850 align:middle line:84% and the whole video game moves down. 00:41:47.850 --> 00:41:48.990 align:middle line:84% There's somehow something very similar 00:41:48.990 --> 00:41:50.615 align:middle line:84% going on here, which is the second I've 00:41:50.615 --> 00:41:52.710 align:middle line:84% managed to get a match for line one of document 00:41:52.710 --> 00:41:54.810 align:middle line:84% into line one of the next document, 00:41:54.810 --> 00:41:58.230 align:middle line:84% I'm just going to throw it away and pretend 00:41:58.230 --> 00:42:01.500 align:middle line:84% like I have two documents with one less line in them. 00:42:01.500 --> 00:42:05.152 align:middle line:84% Now, the thing that got me all hung up last night, 00:42:05.152 --> 00:42:07.360 align:middle line:84% my original problem assumes that both of my documents 00:42:07.360 --> 00:42:09.600 align:middle line:90% have the same length. 00:42:09.600 --> 00:42:12.840 align:middle line:84% But here, I'm not making that assumption, right? 00:42:12.840 --> 00:42:15.030 align:middle line:84% And, essentially, what we're going to figure out 00:42:15.030 --> 00:42:17.072 align:middle line:84% is that that actually doesn't matter a whole lot, 00:42:17.072 --> 00:42:20.340 align:middle line:84% that if I end up with one document of length k-- 00:42:20.340 --> 00:42:21.750 align:middle line:90% well, I shouldn't use k-- 00:42:21.750 --> 00:42:25.380 align:middle line:84% one document of length l and another document of length 0, 00:42:25.380 --> 00:42:27.850 align:middle line:84% what's the amount of work that I should do to convert? 00:42:27.850 --> 00:42:33.300 align:middle line:84% Well, l, because my only choice is to insert a bunch of lines 00:42:33.300 --> 00:42:36.785 align:middle line:84% in one document, by the way, or delete a bunch of lines 00:42:36.785 --> 00:42:37.410 align:middle line:90% from the other. 00:42:37.410 --> 00:42:38.660 align:middle line:90% Those are dual to one another. 00:42:38.660 --> 00:42:40.290 align:middle line:90% They're exactly the same. 00:42:40.290 --> 00:42:43.050 align:middle line:84% I'm philosophizing a lot because I'm also convincing myself 00:42:43.050 --> 00:42:45.420 align:middle line:84% that my answer is OK in the process. 00:42:45.420 --> 00:42:46.930 align:middle line:90% OK. 00:42:46.930 --> 00:42:49.080 align:middle line:84% So this is going to be our set subproblems. 00:42:49.080 --> 00:42:53.070 align:middle line:84% And now we have to do the r, right? 00:42:53.070 --> 00:42:57.770 align:middle line:84% We have to relate, something we struggle with in the math 00:42:57.770 --> 00:43:00.020 align:middle line:90% department sometimes. 00:43:00.020 --> 00:43:03.230 align:middle line:84% And, essentially, the way that I went about this 00:43:03.230 --> 00:43:05.720 align:middle line:84% is to just do a billion different cases 00:43:05.720 --> 00:43:08.600 align:middle line:84% of all the possible edits that I could do to line i and line j. 00:43:08.600 --> 00:43:10.350 align:middle line:84% And that's perfectly fine in this problem. 00:43:10.350 --> 00:43:11.870 align:middle line:84% I think the problem is a little slick. 00:43:11.870 --> 00:43:13.500 align:middle line:84% And the way that they're written the solution, 00:43:13.500 --> 00:43:15.020 align:middle line:84% they've convinced themselves that some things are 00:43:15.020 --> 00:43:16.743 align:middle line:84% equivalent to others and removed them. 00:43:16.743 --> 00:43:17.660 align:middle line:90% But you don't have to. 00:43:17.660 --> 00:43:19.160 align:middle line:84% As long as there's a constant number 00:43:19.160 --> 00:43:22.610 align:middle line:90% of cases, your golden Ponyboy. 00:43:22.610 --> 00:43:25.770 align:middle line:84% So, in particular, let's think about some cases. 00:43:25.770 --> 00:43:32.040 align:middle line:84% So first of all, if line i matches line j of my document-- 00:43:32.040 --> 00:43:33.650 align:middle line:84% remember that it's not really line j. 00:43:33.650 --> 00:43:35.450 align:middle line:84% It's like making a document that just 00:43:35.450 --> 00:43:37.930 align:middle line:90% happens to start at line j. 00:43:37.930 --> 00:43:39.600 align:middle line:90% It's like taking scissors. 00:43:39.600 --> 00:43:42.170 align:middle line:84% Well, then I can match them with zero-cost 00:43:42.170 --> 00:43:44.600 align:middle line:84% because the beginnings are in the same place. 00:43:44.600 --> 00:43:46.850 align:middle line:84% And I can move my Tetris came down one, 00:43:46.850 --> 00:43:48.752 align:middle line:90% and that's perfectly fine. 00:43:48.752 --> 00:43:50.460 align:middle line:84% So case one, I think, is the easiest one, 00:43:50.460 --> 00:43:58.680 align:middle line:84% which is if A i equals B j, then I can just 00:43:58.680 --> 00:44:00.510 align:middle line:84% remove that line from both documents 00:44:00.510 --> 00:44:02.920 align:middle line:84% and move forward, in which case-- 00:44:02.920 --> 00:44:04.635 align:middle line:84% I'll use my same goofy notation-- 00:44:04.635 --> 00:44:05.760 align:middle line:90% I'm going to get that x ij. 00:44:05.760 --> 00:44:08.290 align:middle line:90% 00:44:08.290 --> 00:44:10.340 align:middle line:84% Well, I'm going to just increment i and j 00:44:10.340 --> 00:44:15.560 align:middle line:90% and keep going, like that. 00:44:15.560 --> 00:44:17.380 align:middle line:90% Cool? 00:44:17.380 --> 00:44:20.260 align:middle line:84% So what's something else I could do? 00:44:20.260 --> 00:44:22.040 align:middle line:90% I could delete a line. 00:44:22.040 --> 00:44:23.713 align:middle line:90% Yeah, so what happens-- 00:44:23.713 --> 00:44:27.270 align:middle line:90% 00:44:27.270 --> 00:44:28.650 align:middle line:90% OK. 00:44:28.650 --> 00:44:36.210 align:middle line:84% So case two is delete A i, right? 00:44:36.210 --> 00:44:38.498 align:middle line:84% That's a different thing I can do the line i. 00:44:38.498 --> 00:44:39.790 align:middle line:90% Well, now what do I have to do? 00:44:39.790 --> 00:44:41.450 align:middle line:84% I have a document on the left-hand side, 00:44:41.450 --> 00:44:42.450 align:middle line:90% which is 1 line shorter. 00:44:42.450 --> 00:44:44.590 align:middle line:84% And on the right-hand side, nothing changed. 00:44:44.590 --> 00:44:47.920 align:middle line:84% But deleting a line cost me a dollar. 00:44:47.920 --> 00:44:53.020 align:middle line:84% So, in particular, I have that x ij. 00:44:53.020 --> 00:44:53.890 align:middle line:90% Well, what happens? 00:44:53.890 --> 00:45:02.800 align:middle line:84% Well, I got rid of one line, but I had to pay. 00:45:02.800 --> 00:45:03.310 align:middle line:90% OK. 00:45:03.310 --> 00:45:05.740 align:middle line:84% Let's think about some other things. 00:45:05.740 --> 00:45:07.570 align:middle line:90% You could delete B j. 00:45:07.570 --> 00:45:10.693 align:middle line:90% 00:45:10.693 --> 00:45:12.360 align:middle line:84% This case actually isn't in the solution 00:45:12.360 --> 00:45:14.745 align:middle line:84% because it turns out to be unnecessary. 00:45:14.745 --> 00:45:16.620 align:middle line:84% AUDIENCE: Well, we're only allowed to edit A. 00:45:16.620 --> 00:45:18.180 align:middle line:84% JUSTIN SOLOMON: Oh, I'm only allowed to edit A? 00:45:18.180 --> 00:45:20.160 align:middle line:84% Oh, in that case, I don't have to delete B j. 00:45:20.160 --> 00:45:22.202 align:middle line:84% I really didn't read these problems very closely. 00:45:22.202 --> 00:45:23.260 align:middle line:90% That's my bad. 00:45:23.260 --> 00:45:24.760 align:middle line:84% This would have made it much easier. 00:45:24.760 --> 00:45:27.770 align:middle line:84% I really should read these things. 00:45:27.770 --> 00:45:30.670 align:middle line:84% Cool, so that eliminates half of the cases on my notes. 00:45:30.670 --> 00:45:31.960 align:middle line:90% Fabulous. 00:45:31.960 --> 00:45:35.430 align:middle line:84% Incidentally, you could do these things on the other direction 00:45:35.430 --> 00:45:38.830 align:middle line:84% and it really wouldn't change this problem a whole lot. 00:45:38.830 --> 00:45:40.600 align:middle line:84% Sorry, you know, I have this bad habit 00:45:40.600 --> 00:45:43.030 align:middle line:84% when I'm reading research papers of reading the research paper I 00:45:43.030 --> 00:45:44.590 align:middle line:84% wanted to be there instead of the one 00:45:44.590 --> 00:45:46.210 align:middle line:90% that's actually on the paper. 00:45:46.210 --> 00:45:48.980 align:middle line:84% And, somehow, it's very similar phenomenon here. 00:45:48.980 --> 00:45:49.480 align:middle line:90% OK. 00:45:49.480 --> 00:45:49.980 align:middle line:90% Right. 00:45:49.980 --> 00:45:50.810 align:middle line:90% So, great. 00:45:50.810 --> 00:45:52.330 align:middle line:84% So I can only edit document A, which 00:45:52.330 --> 00:45:55.510 align:middle line:84% makes this probably easier than what I was worried about. 00:45:55.510 --> 00:45:56.110 align:middle line:90% Fabulous. 00:45:56.110 --> 00:46:00.400 align:middle line:90% In that case-- ah, bananas. 00:46:00.400 --> 00:46:05.670 align:middle line:84% With our third case here, well, let's see, 00:46:05.670 --> 00:46:10.140 align:middle line:90% I could also insert a line. 00:46:10.140 --> 00:46:10.640 align:middle line:90% Let's see. 00:46:10.640 --> 00:46:12.120 align:middle line:90% So what ends up happening there? 00:46:12.120 --> 00:46:14.783 align:middle line:90% So I can only edit document A? 00:46:14.783 --> 00:46:16.700 align:middle line:84% So that makes my cases different than the ones 00:46:16.700 --> 00:46:17.742 align:middle line:90% I wrote down on my notes. 00:46:17.742 --> 00:46:24.506 align:middle line:90% 00:46:24.506 --> 00:46:25.410 align:middle line:90% Sorry. 00:46:25.410 --> 00:46:25.910 align:middle line:90% OK. 00:46:25.910 --> 00:46:36.270 align:middle line:90% 00:46:36.270 --> 00:46:36.770 align:middle line:90% OK. 00:46:36.770 --> 00:46:38.198 align:middle line:90% So if I insert-- 00:46:38.198 --> 00:46:38.990 align:middle line:90% let's do this live. 00:46:38.990 --> 00:46:42.551 align:middle line:84% Yeah, OK, so if I insert a line at line i, 00:46:42.551 --> 00:46:44.930 align:middle line:84% I might as well make it match B j. 00:46:44.930 --> 00:46:46.430 align:middle line:90% There's no reason not to. 00:46:46.430 --> 00:46:47.030 align:middle line:90% Right? 00:46:47.030 --> 00:46:49.980 align:middle line:84% I might as well kill off one element of B while I'm at it. 00:46:49.980 --> 00:46:50.480 align:middle line:90% Yeah? 00:46:50.480 --> 00:46:53.520 align:middle line:84% So if I do that, what ends up happening? 00:46:53.520 --> 00:46:55.520 align:middle line:84% Well, I still have to match line i. 00:46:55.520 --> 00:46:57.650 align:middle line:84% I've just, kind of, moved it lower in my file. 00:46:57.650 --> 00:47:01.730 align:middle line:84% But I've, in essence, killed one line in file B 00:47:01.730 --> 00:47:04.613 align:middle line:84% by making it match this new line that I inserted. 00:47:04.613 --> 00:47:06.530 align:middle line:84% In my notes, because I thought I could edit B, 00:47:06.530 --> 00:47:08.720 align:middle line:84% I said, OK, I can just delete the line in B instead. 00:47:08.720 --> 00:47:11.303 align:middle line:84% And somehow, logically, that's a little easier to think about. 00:47:11.303 --> 00:47:13.830 align:middle line:84% But these are exactly dual to one another. 00:47:13.830 --> 00:47:17.540 align:middle line:90% So, in that case, I have x ij. 00:47:17.540 --> 00:47:19.100 align:middle line:84% Well, I still have to deal with A i. 00:47:19.100 --> 00:47:20.225 align:middle line:90% I haven't gotten rid of it. 00:47:20.225 --> 00:47:22.130 align:middle line:90% But I've matched line j. 00:47:22.130 --> 00:47:27.740 align:middle line:84% So I paid $1 for inserting a line. 00:47:27.740 --> 00:47:30.890 align:middle line:84% And now I have that because I've gotten rid 00:47:30.890 --> 00:47:33.978 align:middle line:90% of a line in the other file. 00:47:33.978 --> 00:47:36.520 align:middle line:84% If I stopped here, by the way, I would have it at a distance. 00:47:36.520 --> 00:47:40.000 align:middle line:84% But, unfortunately for me, I have one additional case, 00:47:40.000 --> 00:47:46.420 align:middle line:84% which is mild irritant, as they say, which is that I can swap. 00:47:46.420 --> 00:47:49.710 align:middle line:90% 00:47:49.710 --> 00:47:52.930 align:middle line:90% First of all, can I always swap? 00:47:52.930 --> 00:47:55.230 align:middle line:84% I mean, I can, but if I swap two lines 00:47:55.230 --> 00:47:57.730 align:middle line:84% and they still don't match the lines on the right-hand side, 00:47:57.730 --> 00:47:59.870 align:middle line:84% I'm kind of hosed, right, because you can convince 00:47:59.870 --> 00:48:01.328 align:middle line:84% yourself that in the next step, I'm 00:48:01.328 --> 00:48:03.520 align:middle line:84% going to have to delete something anyway. 00:48:03.520 --> 00:48:04.518 align:middle line:90% Swapping was free. 00:48:04.518 --> 00:48:07.060 align:middle line:84% If I swap and delete, that's the same thing as just deleting, 00:48:07.060 --> 00:48:09.160 align:middle line:90% so it doesn't really matter. 00:48:09.160 --> 00:48:10.630 align:middle line:84% So, in particular, what that means 00:48:10.630 --> 00:48:13.270 align:middle line:84% is I might as well only check the swap if it actually 00:48:13.270 --> 00:48:14.080 align:middle line:90% helps me. 00:48:14.080 --> 00:48:14.830 align:middle line:90% Yeah? 00:48:14.830 --> 00:48:20.692 align:middle line:84% So, in other words, if I have A-- 00:48:20.692 --> 00:48:23.240 align:middle line:84% now you have to be a little bit careful because I'm swapping. 00:48:23.240 --> 00:48:28.030 align:middle line:84% So if the next guy in A equals B, the current guy in B 00:48:28.030 --> 00:48:36.260 align:middle line:84% and the current guy in A equals the next guy in B. Well, 00:48:36.260 --> 00:48:39.560 align:middle line:84% now I can swap this guy and kill off two lines in my files 00:48:39.560 --> 00:48:40.850 align:middle line:90% while I'm at it, right? 00:48:40.850 --> 00:48:46.190 align:middle line:84% So, in this case, I get that X ij. 00:48:46.190 --> 00:48:48.050 align:middle line:84% Well, swapping doesn't cost me anything, 00:48:48.050 --> 00:48:49.560 align:middle line:90% and I killed off two things. 00:48:49.560 --> 00:48:56.663 align:middle line:90% So that's the recursion. 00:48:56.663 --> 00:48:58.580 align:middle line:84% So if I were to write this out on my homework, 00:48:58.580 --> 00:48:59.450 align:middle line:90% what should I do? 00:48:59.450 --> 00:49:01.610 align:middle line:84% Well, I shouldn't-- I mean, probably if you use this error 00:49:01.610 --> 00:49:03.260 align:middle line:84% notation, I don't think it would be a big deal. 00:49:03.260 --> 00:49:04.730 align:middle line:84% But really, you should add a line 00:49:04.730 --> 00:49:07.010 align:middle line:84% at the bottom saying that I can choose 00:49:07.010 --> 00:49:08.130 align:middle line:90% to do any of these things. 00:49:08.130 --> 00:49:09.860 align:middle line:84% So really, my recursive call is x 00:49:09.860 --> 00:49:14.330 align:middle line:84% ij gets the min of all of these 1, 00:49:14.330 --> 00:49:17.140 align:middle line:84% 2, 3, 4 expressions that I've written here. 00:49:17.140 --> 00:49:19.113 align:middle line:90% OK. 00:49:19.113 --> 00:49:21.363 align:middle line:84% AUDIENCE: What if you have the first condition but not 00:49:21.363 --> 00:49:21.988 align:middle line:90% the second one? 00:49:21.988 --> 00:49:24.405 align:middle line:84% JUSTIN SOLOMON: What if I have the first condition but not 00:49:24.405 --> 00:49:25.230 align:middle line:90% the second one? 00:49:25.230 --> 00:49:28.390 align:middle line:90% Ah, so that's a great question. 00:49:28.390 --> 00:49:30.460 align:middle line:84% Yeah, so the question was like, OK, well, 00:49:30.460 --> 00:49:35.820 align:middle line:84% what if I can match the next line but not the current one. 00:49:35.820 --> 00:49:37.820 align:middle line:84% Well, there's two different things you could do. 00:49:37.820 --> 00:49:39.653 align:middle line:84% You could either make another case for that. 00:49:39.653 --> 00:49:40.630 align:middle line:90% That's perfectly fine. 00:49:40.630 --> 00:49:41.690 align:middle line:90% In fact, you could do that. 00:49:41.690 --> 00:49:43.480 align:middle line:84% You could do that I matched the second condition, not 00:49:43.480 --> 00:49:44.488 align:middle line:90% the first one, whatever. 00:49:44.488 --> 00:49:46.030 align:middle line:84% You can just enumerate as many things 00:49:46.030 --> 00:49:47.530 align:middle line:84% you want as long as they're all true 00:49:47.530 --> 00:49:48.820 align:middle line:90% and there's a constant number. 00:49:48.820 --> 00:49:50.487 align:middle line:84% Alternatively, you can convince yourself 00:49:50.487 --> 00:49:53.410 align:middle line:84% that actually is unnecessary here because a different-- 00:49:53.410 --> 00:49:55.850 align:middle line:90% so that's like swapping. 00:49:55.850 --> 00:49:58.130 align:middle line:84% But then one of those two lines is still a mismatch, 00:49:58.130 --> 00:49:59.922 align:middle line:84% so you're going to have to delete something 00:49:59.922 --> 00:50:00.920 align:middle line:90% in the next step. 00:50:00.920 --> 00:50:03.130 align:middle line:84% So you might as well just delete first, rather than 00:50:03.130 --> 00:50:05.560 align:middle line:90% swap and then delete. 00:50:05.560 --> 00:50:07.850 align:middle line:84% And so that's why that case isn't necessary. 00:50:07.850 --> 00:50:08.350 align:middle line:90% Yeah? 00:50:08.350 --> 00:50:10.017 align:middle line:84% AUDIENCE: [INAUDIBLE] in the first case. 00:50:10.017 --> 00:50:11.320 align:middle line:90% JUSTIN SOLOMON: Exactly. 00:50:11.320 --> 00:50:11.860 align:middle line:90% Exactly. 00:50:11.860 --> 00:50:13.900 align:middle line:84% So if you swapped and you killed a line, then, in effect, 00:50:13.900 --> 00:50:15.858 align:middle line:84% I think it's a combination of case 1 and case 2 00:50:15.858 --> 00:50:18.710 align:middle line:84% here, if you, kind of, expand your recursion out. 00:50:18.710 --> 00:50:20.710 align:middle line:84% But if you're having trouble convincing yourself 00:50:20.710 --> 00:50:23.320 align:middle line:84% of that, that's fine, just add a case here. 00:50:23.320 --> 00:50:25.167 align:middle line:90% Yeah. 00:50:25.167 --> 00:50:26.000 align:middle line:90% Any other questions? 00:50:26.000 --> 00:50:28.625 align:middle line:84% I'm going to ask quickly because this problem makes me nervous. 00:50:28.625 --> 00:50:32.675 align:middle line:90% AUDIENCE: [INAUDIBLE] 00:50:32.675 --> 00:50:33.550 align:middle line:90% JUSTIN SOLOMON: Sure. 00:50:33.550 --> 00:50:33.870 align:middle line:90% OK. 00:50:33.870 --> 00:50:35.912 align:middle line:84% In the worst case, if we've done something wrong, 00:50:35.912 --> 00:50:39.010 align:middle line:84% you can certainly add another case here. 00:50:39.010 --> 00:50:40.640 align:middle line:90% I'll think about it at home. 00:50:40.640 --> 00:50:41.140 align:middle line:90% OK. 00:50:41.140 --> 00:50:44.202 align:middle line:84% So since I've managed to pontificate too long, 00:50:44.202 --> 00:50:45.160 align:middle line:90% let's keep moving here. 00:50:45.160 --> 00:50:47.882 align:middle line:84% AUDIENCE: Can we swap them if they [INAUDIBLE] match? 00:50:47.882 --> 00:50:49.590 align:middle line:84% JUSTIN SOLOMON: Oh, you know, the problem 00:50:49.590 --> 00:50:50.910 align:middle line:90% is it might have been-- 00:50:50.910 --> 00:50:53.050 align:middle line:84% AUDIENCE: --used in the final file. 00:50:53.050 --> 00:50:55.680 align:middle line:84% So if you can make swap one match one of them and not 00:50:55.680 --> 00:50:58.803 align:middle line:90% the other, then that's not OK. 00:50:58.803 --> 00:51:00.970 align:middle line:84% JUSTIN SOLOMON: Yeah, because at the end of the day, 00:51:00.970 --> 00:51:02.010 align:middle line:90% the files have to agree. 00:51:02.010 --> 00:51:03.810 align:middle line:90% Like, you have to match B to A. 00:51:03.810 --> 00:51:05.310 align:middle line:84% AUDIENCE: Swap and delete is cheaper 00:51:05.310 --> 00:51:07.573 align:middle line:84% than doing two deletes and two inserts. 00:51:07.573 --> 00:51:10.380 align:middle line:84% AUDIENCE: No, no, no, but the swap and delete 00:51:10.380 --> 00:51:12.725 align:middle line:84% is illegal because you have to use both ones. 00:51:12.725 --> 00:51:14.100 align:middle line:84% That's a condition in the pocket. 00:51:14.100 --> 00:51:15.350 align:middle line:90% JUSTIN SOLOMON: Oh, I'm sorry. 00:51:15.350 --> 00:51:16.370 align:middle line:90% That's a better answer. 00:51:16.370 --> 00:51:18.037 align:middle line:84% So Jason points out that if I swap, then 00:51:18.037 --> 00:51:21.120 align:middle line:84% I can't delete it because the way the problem is written. 00:51:21.120 --> 00:51:23.350 align:middle line:84% So that effectively removes this case. 00:51:23.350 --> 00:51:24.330 align:middle line:90% Otherwise, I think-- 00:51:24.330 --> 00:51:25.320 align:middle line:90% I guess Erik is-- 00:51:25.320 --> 00:51:26.460 align:middle line:84% AUDIENCE: Actually, there are two important conditions-- 00:51:26.460 --> 00:51:27.150 align:middle line:90% JUSTIN SOLOMON: Oh, sorry. 00:51:27.150 --> 00:51:28.620 align:middle line:84% I've managed to totally botch this, 00:51:28.620 --> 00:51:30.960 align:middle line:90% which is totally unsurprising. 00:51:30.960 --> 00:51:31.820 align:middle line:90% Yeah. 00:51:31.820 --> 00:51:34.590 align:middle line:84% So I think the problem also states that if you swap, 00:51:34.590 --> 00:51:37.460 align:middle line:90% the swap has to be useful. 00:51:37.460 --> 00:51:39.390 align:middle line:84% And that's why this additional case 00:51:39.390 --> 00:51:42.150 align:middle line:84% that Erik is asking about where you swap and then you 00:51:42.150 --> 00:51:45.600 align:middle line:84% match one line but not the other is unnecessary. 00:51:45.600 --> 00:51:48.058 align:middle line:84% You might be able to relax that by just adding a case here, 00:51:48.058 --> 00:51:49.600 align:middle line:84% but since the problem doesn't ask it, 00:51:49.600 --> 00:51:50.920 align:middle line:90% I'm not going to think about. 00:51:50.920 --> 00:51:51.670 align:middle line:90% OK. 00:51:51.670 --> 00:51:52.815 align:middle line:90% Right. 00:51:52.815 --> 00:51:54.690 align:middle line:84% So, under all the assumptions of this problem 00:51:54.690 --> 00:51:56.857 align:middle line:84% that I didn't read but are very important to solving 00:51:56.857 --> 00:51:59.070 align:middle line:84% this problem correctly, I believe 00:51:59.070 --> 00:52:03.940 align:middle line:84% we really have written down all of our cases here. 00:52:03.940 --> 00:52:04.440 align:middle line:90% OK. 00:52:04.440 --> 00:52:09.210 align:middle line:84% So let's continue with our SRTBOT paradigm. 00:52:09.210 --> 00:52:12.540 align:middle line:84% So now we have all of our recursion. 00:52:12.540 --> 00:52:17.010 align:middle line:84% The topological order here is a little bit trickier than normal 00:52:17.010 --> 00:52:19.230 align:middle line:84% because now you've got a two-dimensional array, 00:52:19.230 --> 00:52:22.000 align:middle line:84% but it follows a pattern that's pretty typical here, 00:52:22.000 --> 00:52:31.740 align:middle line:84% which is that x ij only depends on other x ij's 00:52:31.740 --> 00:52:38.150 align:middle line:90% with higher i plus j. 00:52:38.150 --> 00:52:41.030 align:middle line:84% So I think about my graph of subproblems. 00:52:41.030 --> 00:52:43.370 align:middle line:84% If I wrote this in a 2D matrix, it always, kind of, 00:52:43.370 --> 00:52:45.590 align:middle line:84% points down and to the right, maybe, 00:52:45.590 --> 00:52:47.870 align:middle line:84% which is what's making it acyclic. 00:52:47.870 --> 00:52:49.790 align:middle line:84% This is a very typical pattern in these sort 00:52:49.790 --> 00:52:52.710 align:middle line:84% of two-dimensional dynamic programming problem. 00:52:52.710 --> 00:52:53.210 align:middle line:90% All right. 00:52:53.210 --> 00:52:55.310 align:middle line:90% So let's see here, SRTBOT. 00:52:55.310 --> 00:52:57.993 align:middle line:90% So we need our base case. 00:52:57.993 --> 00:52:59.660 align:middle line:84% This isn't too bad because, essentially, 00:52:59.660 --> 00:53:02.600 align:middle line:84% when you have boring documents, they're 00:53:02.600 --> 00:53:05.500 align:middle line:84% very easy to match to one another. 00:53:05.500 --> 00:53:12.735 align:middle line:84% So, in particular, for any i, if I'm at line n plus 1-- 00:53:12.735 --> 00:53:15.110 align:middle line:84% in other words, I have a blank document that I'm matching 00:53:15.110 --> 00:53:16.730 align:middle line:90% to document i-- 00:53:16.730 --> 00:53:20.140 align:middle line:84% well, how much work do I have to do? 00:53:20.140 --> 00:53:21.640 align:middle line:84% You have to be a little bit careful. 00:53:21.640 --> 00:53:24.120 align:middle line:84% This is where the suffix version of this problem is a little bit 00:53:24.120 --> 00:53:25.750 align:middle line:84% more annoying than the prefix one-- 00:53:25.750 --> 00:53:29.070 align:middle line:84% or have I managed to swap those backward again-- 00:53:29.070 --> 00:53:32.010 align:middle line:84% that, in particular, the remaining number of lines 00:53:32.010 --> 00:53:38.140 align:middle line:84% looks like n plus 1 minus i, which is 00:53:38.140 --> 00:53:39.390 align:middle line:90% different than in the problem. 00:53:39.390 --> 00:53:40.848 align:middle line:84% It's just i because they're working 00:53:40.848 --> 00:53:43.740 align:middle line:84% in the other direction-- in the solution, rather. 00:53:43.740 --> 00:53:46.570 align:middle line:84% And similarly, you need a second case for those two here, right? 00:53:46.570 --> 00:53:58.248 align:middle line:84% So you have x n plus 1 j is going to be n plus 1 minus j. 00:53:58.248 --> 00:53:59.730 align:middle line:90% Cool. 00:53:59.730 --> 00:54:01.050 align:middle line:90% OK. 00:54:01.050 --> 00:54:03.620 align:middle line:84% So we're going to continue with SRTBOT here. 00:54:03.620 --> 00:54:06.232 align:middle line:90% 00:54:06.232 --> 00:54:07.440 align:middle line:90% So what is our original case? 00:54:07.440 --> 00:54:13.530 align:middle line:84% Kind of by definition it's x 1, 1 or 0 0, 00:54:13.530 --> 00:54:15.780 align:middle line:90% depending on how you index. 00:54:15.780 --> 00:54:19.450 align:middle line:84% And then, finally, what's our runtime? 00:54:19.450 --> 00:54:27.180 align:middle line:84% Well, let's see, there's n plus 1 squared subproblems, 00:54:27.180 --> 00:54:31.050 align:middle line:84% and, of course, that's equal to order n squared. 00:54:31.050 --> 00:54:34.530 align:middle line:84% The subproblems are just a constant amount of work, 00:54:34.530 --> 00:54:38.780 align:middle line:84% so they're each with constant work. 00:54:38.780 --> 00:54:41.750 align:middle line:90% 00:54:41.750 --> 00:54:46.210 align:middle line:84% So our entire runtime is order n squared. 00:54:46.210 --> 00:54:49.900 align:middle line:84% And hopefully by watching me be confused in front of you 00:54:49.900 --> 00:54:51.550 align:middle line:84% and think through this problem, you too 00:54:51.550 --> 00:54:55.000 align:middle line:84% will see how the problem solving procedure 00:54:55.000 --> 00:54:57.920 align:middle line:84% can happen in your own disorganized brains. 00:54:57.920 --> 00:54:58.420 align:middle line:90% OK. 00:54:58.420 --> 00:55:03.780 align:middle line:84% So that concludes our treatment of this problem here. 00:55:03.780 --> 00:55:05.300 align:middle line:84% That, I think, is the hardest one. 00:55:05.300 --> 00:55:08.820 align:middle line:84% So the other two, thankfully, are much easier to think about, 00:55:08.820 --> 00:55:10.327 align:middle line:90% I thought. 00:55:10.327 --> 00:55:11.660 align:middle line:90% But I never liked edit distance. 00:55:11.660 --> 00:55:13.961 align:middle line:84% I remember seeing that and undergrad algorithms getting 00:55:13.961 --> 00:55:14.670 align:middle line:90% confused. 00:55:14.670 --> 00:55:15.190 align:middle line:90% OK. 00:55:15.190 --> 00:55:22.800 align:middle line:84% So the next problem, problem 3 here, deals with Saggy Mimsin. 00:55:22.800 --> 00:55:25.260 align:middle line:84% And she has a bunch of block, and she 00:55:25.260 --> 00:55:28.420 align:middle line:84% wants to stack them on top of each other, as one does. 00:55:28.420 --> 00:55:31.740 align:middle line:84% And as a young structural engineer, 00:55:31.740 --> 00:55:34.790 align:middle line:84% she has a few criteria on her problem. 00:55:34.790 --> 00:55:37.850 align:middle line:90% 00:55:37.850 --> 00:55:40.110 align:middle line:84% Let me go to the right page in my notes here. 00:55:40.110 --> 00:55:44.190 align:middle line:90% 00:55:44.190 --> 00:55:46.140 align:middle line:90% Right. 00:55:46.140 --> 00:55:48.090 align:middle line:90% So this is problem 3. 00:55:48.090 --> 00:55:59.040 align:middle line:84% So we have that block bi has size that looks like width wi 00:55:59.040 --> 00:56:03.950 align:middle line:90% by height hi by length li. 00:56:03.950 --> 00:56:06.090 align:middle line:84% I remember getting confused in elementary school 00:56:06.090 --> 00:56:08.580 align:middle line:84% about the difference between width and length all the time. 00:56:08.580 --> 00:56:10.320 align:middle line:84% To me, those always sounded the same. 00:56:10.320 --> 00:56:12.112 align:middle line:84% But it doesn't really matter, because she's 00:56:12.112 --> 00:56:16.740 align:middle line:84% happy to rotate her cubes any way that she pleases. 00:56:16.740 --> 00:56:19.680 align:middle line:84% There's a key detail which I did remember to actually read 00:56:19.680 --> 00:56:24.450 align:middle line:84% in this problem, which is that she has at least three 00:56:24.450 --> 00:56:31.333 align:middle line:84% of each type, where type here means that I can permute 00:56:31.333 --> 00:56:32.750 align:middle line:84% these three numbers any way that I 00:56:32.750 --> 00:56:35.180 align:middle line:84% want because that's the same as just rotating a block. 00:56:35.180 --> 00:56:38.240 align:middle line:84% But any time she has one block that's like 1 by 2 by 3, 00:56:38.240 --> 00:56:41.200 align:middle line:84% she has at least two more in her bag somewhere. 00:56:41.200 --> 00:56:41.746 align:middle line:90% OK. 00:56:41.746 --> 00:56:44.240 align:middle line:90% APPLE WATCH: It's 6. 00:56:44.240 --> 00:56:46.940 align:middle line:84% JUSTIN SOLOMON: Oh, 1 times 2 times 3 is equal to 6. 00:56:46.940 --> 00:56:48.900 align:middle line:90% Thank you, Apple Watch. 00:56:48.900 --> 00:56:49.560 align:middle line:90% OK. 00:56:49.560 --> 00:56:51.490 align:middle line:90% So that's odd. 00:56:51.490 --> 00:56:53.060 align:middle line:84% So she can orient her block any way 00:56:53.060 --> 00:56:58.010 align:middle line:84% that she wants, meaning she can rotate it in any fashion 00:56:58.010 --> 00:56:59.150 align:middle line:90% that she'd like. 00:56:59.150 --> 00:57:02.930 align:middle line:84% And so what we're trying to do, what we want 00:57:02.930 --> 00:57:10.380 align:middle line:84% is the max height where she's stacking her n blocks. 00:57:10.380 --> 00:57:15.720 align:middle line:84% I suppose I should say they're n blocks. 00:57:15.720 --> 00:57:18.210 align:middle line:84% So she wants the max height that she can achieve. 00:57:18.210 --> 00:57:22.120 align:middle line:84% But just to be kind of annoying, or because, again, 00:57:22.120 --> 00:57:24.120 align:middle line:84% she's very concerned with structural stability-- 00:57:24.120 --> 00:57:25.680 align:middle line:84% she lives in an earthquake zone-- 00:57:25.680 --> 00:57:29.670 align:middle line:84% she would like with the condition 00:57:29.670 --> 00:57:33.360 align:middle line:84% that each block is strictly supported on the block 00:57:33.360 --> 00:57:34.000 align:middle line:90% beneath it. 00:57:34.000 --> 00:57:34.500 align:middle line:90% Right? 00:57:34.500 --> 00:57:40.350 align:middle line:90% 00:57:40.350 --> 00:57:44.580 align:middle line:84% So in other words, if this is the base of one block, 00:57:44.580 --> 00:57:46.980 align:middle line:84% then the next block that's stacked on top of it 00:57:46.980 --> 00:57:51.950 align:middle line:84% has to be strictly contained within the block below it. 00:57:51.950 --> 00:57:52.980 align:middle line:90% Right? 00:57:52.980 --> 00:57:54.615 align:middle line:90% So does the problem make sense? 00:57:54.615 --> 00:57:56.668 align:middle line:84% Have I omitted any critical details? 00:57:56.668 --> 00:57:57.960 align:middle line:90% I don't think I have this time. 00:57:57.960 --> 00:57:59.618 align:middle line:90% This one's a little easier. 00:57:59.618 --> 00:58:01.748 align:middle line:90% AUDIENCE: [INAUDIBLE] 00:58:01.748 --> 00:58:02.790 align:middle line:90% JUSTIN SOLOMON: Oh, yeah. 00:58:02.790 --> 00:58:04.123 align:middle line:90% And she can't do anything crazy. 00:58:04.123 --> 00:58:06.660 align:middle line:84% She can't do a weird, like, balance it 00:58:06.660 --> 00:58:09.000 align:middle line:84% on this edge kind of thing, which-- 00:58:09.000 --> 00:58:12.802 align:middle line:84% Erik is absolutely right-- could actually give her a taller 00:58:12.802 --> 00:58:14.760 align:middle line:84% tower than you could get if you're only allowed 00:58:14.760 --> 00:58:16.320 align:middle line:90% to rotate blocks 90 degrees. 00:58:16.320 --> 00:58:18.900 align:middle line:84% I don't think the problem states that explicitly, but this 00:58:18.900 --> 00:58:21.900 align:middle line:84% isn't a trigonometry class, so I think we're in good shape. 00:58:21.900 --> 00:58:23.710 align:middle line:90% OK. 00:58:23.710 --> 00:58:24.210 align:middle line:90% Right. 00:58:24.210 --> 00:58:27.337 align:middle line:84% So that's our basic problem here. 00:58:27.337 --> 00:58:28.920 align:middle line:84% And this is one of these problems that 00:58:28.920 --> 00:58:30.795 align:middle line:84% is going to be a dynamic programming problem, 00:58:30.795 --> 00:58:33.180 align:middle line:84% but, again, similar to many of the things that we 00:58:33.180 --> 00:58:36.000 align:middle line:84% saw in lecture, is not totally obvious how, 00:58:36.000 --> 00:58:39.720 align:middle line:84% because somehow she has this big, disorganized bag 00:58:39.720 --> 00:58:40.440 align:middle line:90% of blocks. 00:58:40.440 --> 00:58:41.880 align:middle line:84% You could imagine a universe where 00:58:41.880 --> 00:58:45.155 align:middle line:84% there's 2 to the n different things she could do, right? 00:58:45.155 --> 00:58:46.530 align:middle line:84% For every single block, she could 00:58:46.530 --> 00:58:48.747 align:middle line:84% decide whether or not to put it in her stack, 00:58:48.747 --> 00:58:50.580 align:middle line:84% and then she has to do a bunch of other work 00:58:50.580 --> 00:58:52.950 align:middle line:84% to verify whether she can stack them 00:58:52.950 --> 00:58:56.410 align:middle line:84% while supporting the strict support condition or not. 00:58:56.410 --> 00:58:59.200 align:middle line:84% So, initially, that seems kind of annoying. 00:58:59.200 --> 00:59:01.137 align:middle line:84% So what we have to do, which, again, 00:59:01.137 --> 00:59:02.970 align:middle line:84% is pretty common to a lot of these problems, 00:59:02.970 --> 00:59:05.520 align:middle line:90% is place some order on it. 00:59:05.520 --> 00:59:07.300 align:middle line:84% I mean that both in the entropy sense, 00:59:07.300 --> 00:59:09.930 align:middle line:84% and also, like, literally, were going to order stuff. 00:59:09.930 --> 00:59:12.420 align:middle line:84% And, in particular, we'll see that this problem has 00:59:12.420 --> 00:59:14.610 align:middle line:84% a lot in common with that longest 00:59:14.610 --> 00:59:17.880 align:middle line:84% common subsequence problem that we saw in lecture-- increasing 00:59:17.880 --> 00:59:20.670 align:middle line:90% subsequence, sorry. 00:59:20.670 --> 00:59:21.750 align:middle line:90% Right. 00:59:21.750 --> 00:59:26.860 align:middle line:84% So here's some observations about our problem 00:59:26.860 --> 00:59:28.350 align:middle line:90% which are going to help. 00:59:28.350 --> 00:59:33.260 align:middle line:84% First of all, when we stack our blocks, 00:59:33.260 --> 00:59:36.860 align:middle line:84% we might as well always align the shorter side of the block 00:59:36.860 --> 00:59:40.470 align:middle line:84% on top to the shorter side of the block underneath it. 00:59:40.470 --> 00:59:40.970 align:middle line:90% Right? 00:59:40.970 --> 00:59:43.598 align:middle line:90% 00:59:43.598 --> 00:59:45.140 align:middle line:84% Let me draw a picture of what I mean. 00:59:45.140 --> 00:59:50.900 align:middle line:90% 00:59:50.900 --> 00:59:52.645 align:middle line:90% So let's say I have a really-- 00:59:52.645 --> 00:59:54.920 align:middle line:84% a block whose base kind of looks like that 00:59:54.920 --> 00:59:58.300 align:middle line:84% and then another block which is also rectangular 00:59:58.300 --> 01:00:01.390 align:middle line:84% that I sit on top of it like that. 01:00:01.390 --> 01:00:04.748 align:middle line:84% Then notice I could-- so in this case, the shorter edge of one 01:00:04.748 --> 01:00:06.790 align:middle line:84% block is aligned to the longer edge of the other. 01:00:06.790 --> 01:00:09.640 align:middle line:84% Notice I can rotate it 90 degrees and it 01:00:09.640 --> 01:00:11.780 align:middle line:90% still supports on one another. 01:00:11.780 --> 01:00:13.240 align:middle line:90% So there's never a case-- 01:00:13.240 --> 01:00:16.030 align:middle line:84% you convince yourself with just a few inequalities-- 01:00:16.030 --> 01:00:18.640 align:middle line:84% where I don't, kind of, always put the long side parallel 01:00:18.640 --> 01:00:21.040 align:middle line:84% to the long side of the guy underneath and the short side 01:00:21.040 --> 01:00:22.740 align:middle line:84% parallel to the short guy underneath it. 01:00:22.740 --> 01:00:24.570 align:middle line:90% Does that makes sense? 01:00:24.570 --> 01:00:25.070 align:middle line:90% Cool. 01:00:25.070 --> 01:00:26.640 align:middle line:90% So that's observation one. 01:00:26.640 --> 01:00:29.990 align:middle line:90% 01:00:29.990 --> 01:00:33.350 align:middle line:84% Observation two, can they ever-- like, 01:00:33.350 --> 01:00:36.650 align:middle line:84% let's say that Maggie actually-- sorry, 01:00:36.650 --> 01:00:41.000 align:middle line:84% Saggy actually had not just three blocks of a type, 01:00:41.000 --> 01:00:43.020 align:middle line:90% but like 25. 01:00:43.020 --> 01:00:46.670 align:middle line:90% So she's just has hella blocks. 01:00:46.670 --> 01:00:49.110 align:middle line:90% My question is does it matter. 01:00:49.110 --> 01:00:54.978 align:middle line:84% The answer is no because this word here is really critical, 01:00:54.978 --> 01:00:56.520 align:middle line:84% which is that there's strict support. 01:00:56.520 --> 01:00:59.880 align:middle line:84% So your block only has so many faces. 01:00:59.880 --> 01:01:03.330 align:middle line:84% And, in fact, by observation one, 01:01:03.330 --> 01:01:07.230 align:middle line:84% really all that matters is which of the three types of faces 01:01:07.230 --> 01:01:11.080 align:middle line:84% is sitting on top because we can just always rotate it. 01:01:11.080 --> 01:01:17.400 align:middle line:84% So there's three configurations of every block, so, at most, 01:01:17.400 --> 01:01:20.380 align:middle line:84% can any one configuration appear more than one time? 01:01:20.380 --> 01:01:22.530 align:middle line:84% No, because of the strict support condition. 01:01:22.530 --> 01:01:23.030 align:middle line:90% Right? 01:01:23.030 --> 01:01:24.738 align:middle line:84% Otherwise, the rectangles would match up, 01:01:24.738 --> 01:01:27.570 align:middle line:90% and that's against the rules. 01:01:27.570 --> 01:01:32.470 align:middle line:84% So, in particular-- oops, the number after two is-- 01:01:32.470 --> 01:01:37.280 align:middle line:84% the number after 1 is 2, which looks like that. 01:01:37.280 --> 01:01:38.960 align:middle line:90% OK. 01:01:38.960 --> 01:01:39.460 align:middle line:90% Right. 01:01:39.460 --> 01:01:43.430 align:middle line:84% So, in particular, there are only three orientations. 01:01:43.430 --> 01:01:47.530 align:middle line:90% 01:01:47.530 --> 01:01:49.630 align:middle line:84% This is just which of the three edges of the block 01:01:49.630 --> 01:01:52.810 align:middle line:84% is the one that's going away from the floor, the normal 01:01:52.810 --> 01:01:54.130 align:middle line:90% to the ground. 01:01:54.130 --> 01:02:01.810 align:middle line:84% And moreover, each can appear less than or equal to 1 time. 01:02:01.810 --> 01:02:05.210 align:middle line:84% That's good because it limits the size of our problem. 01:02:05.210 --> 01:02:13.840 align:middle line:84% And, finally-- oops, I collapsed two of the cases in my notes 01:02:13.840 --> 01:02:15.100 align:middle line:90% into one case here. 01:02:15.100 --> 01:02:16.363 align:middle line:90% But that's OK. 01:02:16.363 --> 01:02:18.280 align:middle line:84% And, in fact, notice that the problem tells us 01:02:18.280 --> 01:02:20.210 align:middle line:84% that she has at least three of each type. 01:02:20.210 --> 01:02:23.960 align:middle line:90% So, in a sense, if the problem-- 01:02:23.960 --> 01:02:26.870 align:middle line:84% if you observe one of a block you might as well just 01:02:26.870 --> 01:02:28.760 align:middle line:84% throw away the rest because you know that you 01:02:28.760 --> 01:02:30.230 align:middle line:90% can use it at most three times. 01:02:30.230 --> 01:02:31.652 align:middle line:90% And she has three of that block. 01:02:31.652 --> 01:02:33.860 align:middle line:84% We can't use it more than three times, so in a sense, 01:02:33.860 --> 01:02:36.200 align:middle line:84% that's just superfluous information. 01:02:36.200 --> 01:02:37.420 align:middle line:90% OK. 01:02:37.420 --> 01:02:37.920 align:middle line:90% Right. 01:02:37.920 --> 01:02:42.620 align:middle line:84% So this allows us to put a little bit of order 01:02:42.620 --> 01:02:45.290 align:middle line:84% here, because notice that when I look at the stack of blocks 01:02:45.290 --> 01:02:46.790 align:middle line:90% here, what do we know? 01:02:46.790 --> 01:02:49.940 align:middle line:84% If I look at the length of the long side 01:02:49.940 --> 01:02:54.050 align:middle line:84% and the length of the short side in the plane of the ground, 01:02:54.050 --> 01:02:57.780 align:middle line:84% those numbers have to decrease on every level of my block. 01:02:57.780 --> 01:02:58.780 align:middle line:90% They can never increase. 01:02:58.780 --> 01:03:00.738 align:middle line:84% That's what the strict support conditions says, 01:03:00.738 --> 01:03:03.350 align:middle line:84% combined with observation one, actually, even 01:03:03.350 --> 01:03:07.345 align:middle line:84% without observation one, which is good news, right? 01:03:07.345 --> 01:03:09.470 align:middle line:84% So this is what's going to allow us to impose order 01:03:09.470 --> 01:03:12.290 align:middle line:84% on our problem, namely, that we can sort by the edge lengths 01:03:12.290 --> 01:03:14.670 align:middle line:84% because we know that we have this support condition. 01:03:14.670 --> 01:03:15.170 align:middle line:90% OK. 01:03:15.170 --> 01:03:18.015 align:middle line:84% So let's fill in some details of our algorithm. 01:03:18.015 --> 01:03:20.550 align:middle line:90% 01:03:20.550 --> 01:03:21.050 align:middle line:90% OK. 01:03:21.050 --> 01:03:26.310 align:middle line:90% 01:03:26.310 --> 01:03:30.090 align:middle line:84% So originally-- already we can see that our list of blocks 01:03:30.090 --> 01:03:32.000 align:middle line:84% is kind of useless because the width, length, 01:03:32.000 --> 01:03:36.150 align:middle line:84% and values are sorted in ways that don't matter. 01:03:36.150 --> 01:03:39.030 align:middle line:84% Moreover, if we have more than three of a given block, 01:03:39.030 --> 01:03:42.130 align:middle line:90% that's somehow not super useful. 01:03:42.130 --> 01:03:47.500 align:middle line:84% So, instead of that, without loss of generality, 01:03:47.500 --> 01:03:48.310 align:middle line:90% let's assume-- 01:03:48.310 --> 01:03:56.238 align:middle line:84% so WLOG here-- we can always take our block and assume-- 01:03:56.238 --> 01:03:58.530 align:middle line:84% I'm going to do this slightly different from my notes-- 01:03:58.530 --> 01:04:06.553 align:middle line:84% that the width is less than or equal to the height is less 01:04:06.553 --> 01:04:07.720 align:middle line:90% than or equal to the length. 01:04:07.720 --> 01:04:08.220 align:middle line:90% OK. 01:04:08.220 --> 01:04:10.570 align:middle line:84% So every block, if this isn't the case, 01:04:10.570 --> 01:04:12.460 align:middle line:84% I could go down my array of blocks and sort. 01:04:12.460 --> 01:04:15.700 align:middle line:84% And sorting a list of three numbers is constant time. 01:04:15.700 --> 01:04:17.800 align:middle line:90% OK? 01:04:17.800 --> 01:04:18.820 align:middle line:90% Right. 01:04:18.820 --> 01:04:21.100 align:middle line:84% So what does this allow me to do? 01:04:21.100 --> 01:04:24.670 align:middle line:84% Well, I'm going to say that a block type actually 01:04:24.670 --> 01:04:28.450 align:middle line:84% is an ordered set where the third number is going 01:04:28.450 --> 01:04:30.710 align:middle line:90% to be the axis that points up. 01:04:30.710 --> 01:04:32.210 align:middle line:84% And the reason to do that is that we 01:04:32.210 --> 01:04:34.160 align:middle line:84% know that we can never use that more than once 01:04:34.160 --> 01:04:35.600 align:middle line:90% for any type of a block. 01:04:35.600 --> 01:04:36.260 align:middle line:90% Yeah? 01:04:36.260 --> 01:04:47.360 align:middle line:84% So now I'm going to make a new list of blocks with a capital B 01:04:47.360 --> 01:04:50.390 align:middle line:90% because I like blocks. 01:04:50.390 --> 01:04:52.590 align:middle line:84% And it's going to look like the following. 01:04:52.590 --> 01:04:57.673 align:middle line:84% So if width-- so if w is less than h is less than l, 01:04:57.673 --> 01:04:59.090 align:middle line:84% then I'm going to take every block 01:04:59.090 --> 01:05:02.488 align:middle line:90% and duplicate it three times. 01:05:02.488 --> 01:05:04.780 align:middle line:84% Notice that I might end up with a list with, like, nine 01:05:04.780 --> 01:05:09.100 align:middle line:84% times of every block, but we'll fix that later. 01:05:09.100 --> 01:05:09.610 align:middle line:90% Right. 01:05:09.610 --> 01:05:12.670 align:middle line:84% And it's going to look like the following, which 01:05:12.670 --> 01:05:19.270 align:middle line:84% is that, OK, I'm going to have wi, hi, li. 01:05:19.270 --> 01:05:22.000 align:middle line:84% This is like describing a way to stack my block because it's 01:05:22.000 --> 01:05:25.240 align:middle line:84% saying this is the short side, this is the long side, 01:05:25.240 --> 01:05:28.210 align:middle line:90% this is the vertical side. 01:05:28.210 --> 01:05:30.730 align:middle line:84% And there are three cases where any one of these guys 01:05:30.730 --> 01:05:31.810 align:middle line:90% can be the vertical side. 01:05:31.810 --> 01:05:33.080 align:middle line:90% So there's one. 01:05:33.080 --> 01:05:36.370 align:middle line:84% Let's say that the h is the vertical side, 01:05:36.370 --> 01:05:38.380 align:middle line:90% then w has to go before l. 01:05:38.380 --> 01:05:45.010 align:middle line:84% So it would be wi, li, hi, and a third one 01:05:45.010 --> 01:05:48.010 align:middle line:90% where the third guy is w. 01:05:48.010 --> 01:05:52.420 align:middle line:84% H is less than l, so it would be hi, li, wi. 01:05:52.420 --> 01:05:53.920 align:middle line:84% And those are all the different ways 01:05:53.920 --> 01:05:57.730 align:middle line:84% that I can, sort of, orient these blocks in my stacking, 01:05:57.730 --> 01:06:02.710 align:middle line:84% assuming that I impose condition one for convenience here. 01:06:02.710 --> 01:06:03.737 align:middle line:90% OK. 01:06:03.737 --> 01:06:05.320 align:middle line:84% I'm going to make a new list of blocks 01:06:05.320 --> 01:06:07.507 align:middle line:84% where I take every block in my original set 01:06:07.507 --> 01:06:09.340 align:middle line:84% and I just duplicate it three times this way 01:06:09.340 --> 01:06:12.730 align:middle line:90% after I sort its coordinates. 01:06:12.730 --> 01:06:14.655 align:middle line:84% And now, well, what do I need to do? 01:06:14.655 --> 01:06:16.780 align:middle line:84% For one thing, this thing may have too many blocks. 01:06:16.780 --> 01:06:19.072 align:middle line:84% I might have a block that's repeated more than one time 01:06:19.072 --> 01:06:20.198 align:middle line:90% and I can't do that. 01:06:20.198 --> 01:06:22.240 align:middle line:84% And moreover, it's going to be convenient to have 01:06:22.240 --> 01:06:25.090 align:middle line:84% this sorted because I've got to stack these guys eventually. 01:06:25.090 --> 01:06:25.810 align:middle line:90% Yeah? 01:06:25.810 --> 01:06:30.670 align:middle line:90% So I'm going to sort that list. 01:06:30.670 --> 01:06:31.960 align:middle line:90% And I want to do it-- 01:06:31.960 --> 01:06:34.790 align:middle line:84% I can never say this word-- lexicographically, 01:06:34.790 --> 01:06:37.630 align:middle line:84% meaning that I'm going sort out the first coordinate, and then 01:06:37.630 --> 01:06:45.410 align:middle line:84% the second and the third lexicographically. 01:06:45.410 --> 01:06:49.190 align:middle line:84% Notice this length is 3 n if I had n blocks to start with. 01:06:49.190 --> 01:06:54.830 align:middle line:84% So this entire thing takes order n log n time, which 01:06:54.830 --> 01:06:57.570 align:middle line:90% is important to account for. 01:06:57.570 --> 01:06:59.210 align:middle line:84% And then I can remove duplicates. 01:06:59.210 --> 01:07:03.072 align:middle line:90% 01:07:03.072 --> 01:07:04.530 align:middle line:84% I'll let you guys convince yourself 01:07:04.530 --> 01:07:06.510 align:middle line:90% you can do this in order n time. 01:07:06.510 --> 01:07:08.970 align:middle line:84% An easier way would've been making second array and just 01:07:08.970 --> 01:07:09.570 align:middle line:90% kind of move-- 01:07:09.570 --> 01:07:11.520 align:middle line:84% and only add stuff when you didn't 01:07:11.520 --> 01:07:13.410 align:middle line:90% see the same thing before. 01:07:13.410 --> 01:07:14.430 align:middle line:90% OK. 01:07:14.430 --> 01:07:18.030 align:middle line:84% And, finally, now these are ordered in a really nice way 01:07:18.030 --> 01:07:20.970 align:middle line:84% because I can stack my blocks, but only 01:07:20.970 --> 01:07:22.620 align:middle line:84% ever looking to the right in my sorted 01:07:22.620 --> 01:07:28.880 align:middle line:84% list, assuming that I'm stacking from the top of my tower down, 01:07:28.880 --> 01:07:33.050 align:middle line:84% which is, I think, sort of what's going on in this thing. 01:07:33.050 --> 01:07:33.590 align:middle line:90% OK. 01:07:33.590 --> 01:07:37.080 align:middle line:84% So now, finally, we can do our SRTBOT. 01:07:37.080 --> 01:07:40.092 align:middle line:84% And I might do S and R and T and then allow you 01:07:40.092 --> 01:07:42.050 align:middle line:84% guys to think about the rest because, as usual, 01:07:42.050 --> 01:07:43.680 align:middle line:90% I'm talking too much. 01:07:43.680 --> 01:07:44.180 align:middle line:90% OK. 01:07:44.180 --> 01:07:49.580 align:middle line:84% So now this is starting to look like a subsequence problem 01:07:49.580 --> 01:07:52.460 align:middle line:84% because, essentially, when I stuck my blocks, if I 01:07:52.460 --> 01:07:54.140 align:middle line:90% use this block here-- 01:07:54.140 --> 01:07:57.560 align:middle line:84% again, if I'm stacking from my tower from the top down-- 01:07:57.560 --> 01:08:00.200 align:middle line:84% all the blocks that can sit underneath this one 01:08:00.200 --> 01:08:03.680 align:middle line:84% have to be further to the right in my array because of the way 01:08:03.680 --> 01:08:06.190 align:middle line:90% that I sorted. 01:08:06.190 --> 01:08:08.740 align:middle line:84% Now, that doesn't mean that I can put anything 01:08:08.740 --> 01:08:10.510 align:middle line:84% on the right underneath this guy, 01:08:10.510 --> 01:08:12.640 align:middle line:84% but it does mean that I know nothing to the left 01:08:12.640 --> 01:08:13.780 align:middle line:90% can go underneath this guy. 01:08:13.780 --> 01:08:15.460 align:middle line:84% That's the way to think about it. 01:08:15.460 --> 01:08:16.120 align:middle line:90% OK. 01:08:16.120 --> 01:08:18.220 align:middle line:90% So it is going to be SRTBOT. 01:08:18.220 --> 01:08:23.439 align:middle line:84% So S, what I'm going to say is that x i here 01:08:23.439 --> 01:08:27.700 align:middle line:84% is equal to the maximum height of my tower, and I'm going to-- 01:08:27.700 --> 01:08:29.140 align:middle line:84% taking a little bit of inspiration 01:08:29.140 --> 01:08:32.350 align:middle line:84% from our subsequence problem that we've already seen, 01:08:32.350 --> 01:08:34.720 align:middle line:84% I'm going to force myself to use block i. 01:08:34.720 --> 01:08:36.105 align:middle line:90% We'll see if that's convenient. 01:08:36.105 --> 01:08:46.310 align:middle line:90% 01:08:46.310 --> 01:08:54.729 align:middle line:84% i and possibly-- just for fun, maybe we'll 01:08:54.729 --> 01:08:58.460 align:middle line:84% do the prefix version of this problem this time. 01:08:58.460 --> 01:09:04.310 align:middle line:84% So now I can use any of the previous blocks. 01:09:04.310 --> 01:09:06.800 align:middle line:84% So I can use the first i blocks to make a tower, 01:09:06.800 --> 01:09:08.547 align:middle line:90% but I'm forced to use block i. 01:09:08.547 --> 01:09:10.380 align:middle line:84% By the way, from now on, when I use indices, 01:09:10.380 --> 01:09:12.290 align:middle line:90% it's into this sorted array. 01:09:12.290 --> 01:09:14.840 align:middle line:90% OK. 01:09:14.840 --> 01:09:15.740 align:middle line:90% So this is a problem. 01:09:15.740 --> 01:09:18.260 align:middle line:84% Obviously, if I could solve for x, 01:09:18.260 --> 01:09:20.600 align:middle line:84% I would be done, because I could get the maximum height 01:09:20.600 --> 01:09:23.330 align:middle line:84% by just iterating over all the x's and choosing the biggest 01:09:23.330 --> 01:09:25.770 align:middle line:90% possible value here. 01:09:25.770 --> 01:09:27.979 align:middle line:84% And the question is, how do I do this recursively? 01:09:27.979 --> 01:09:32.950 align:middle line:90% 01:09:32.950 --> 01:09:33.450 align:middle line:90% OK. 01:09:33.450 --> 01:09:37.600 align:middle line:90% So here's our recursive step. 01:09:37.600 --> 01:09:42.029 align:middle line:84% So let's say that I use block i, well, 01:09:42.029 --> 01:09:43.830 align:middle line:90% because we know we have to. 01:09:43.830 --> 01:09:44.760 align:middle line:90% Right? 01:09:44.760 --> 01:09:49.140 align:middle line:90% So, in particular, we have-- 01:09:49.140 --> 01:09:51.779 align:middle line:84% now I'm seeing why they didn't use this notation 01:09:51.779 --> 01:09:53.130 align:middle line:90% in their answer, but that's OK. 01:09:53.130 --> 01:10:00.370 align:middle line:90% 01:10:00.370 --> 01:10:03.010 align:middle line:84% Let's use another letter to refer to the third coordinate. 01:10:03.010 --> 01:10:06.413 align:middle line:90% 01:10:06.413 --> 01:10:08.080 align:middle line:84% AUDIENCE: v i for vertical [INAUDIBLE].. 01:10:08.080 --> 01:10:09.700 align:middle line:84% JUSTIN SOLOMON: Yeah, let's say v i is always 01:10:09.700 --> 01:10:10.210 align:middle line:90% the third coordinate. 01:10:10.210 --> 01:10:11.620 align:middle line:84% We've already used w, h, and l, and I'm 01:10:11.620 --> 01:10:13.210 align:middle line:84% afraid if I reuse them after sorting, 01:10:13.210 --> 01:10:14.980 align:middle line:90% it's going to confuse people. 01:10:14.980 --> 01:10:22.030 align:middle line:84% So v i is the third coordinate of the i-th element 01:10:22.030 --> 01:10:23.920 align:middle line:90% of my sorted array. 01:10:23.920 --> 01:10:26.560 align:middle line:90% That's fine, OK. 01:10:26.560 --> 01:10:31.600 align:middle line:84% Right, so what is my height if I use x i here? 01:10:31.600 --> 01:10:34.155 align:middle line:90% Well, I get some height from vi. 01:10:34.155 --> 01:10:35.780 align:middle line:84% And in addition to that, I get whatever 01:10:35.780 --> 01:10:39.220 align:middle line:90% I stack underneath that guy. 01:10:39.220 --> 01:10:43.652 align:middle line:84% So, in particular, I get that xi. 01:10:43.652 --> 01:10:45.110 align:middle line:84% Well, I get the height of the block 01:10:45.110 --> 01:10:47.390 align:middle line:90% that I just decided to use. 01:10:47.390 --> 01:10:50.930 align:middle line:90% And now, what are all my cases? 01:10:50.930 --> 01:10:53.120 align:middle line:84% Well, I could decide to do nothing else, 01:10:53.120 --> 01:10:55.110 align:middle line:84% like, just not use any other blocks. 01:10:55.110 --> 01:10:57.740 align:middle line:90% That gives me a height of 0. 01:10:57.740 --> 01:11:02.940 align:middle line:90% Or, well, let's see here. 01:11:02.940 --> 01:11:05.100 align:middle line:84% I could use the x's, but I have to be careful 01:11:05.100 --> 01:11:07.140 align:middle line:90% that I can actually stack them. 01:11:07.140 --> 01:11:12.225 align:middle line:84% So, in particular, well, I need-- 01:11:12.225 --> 01:11:15.330 align:middle line:90% 01:11:15.330 --> 01:11:20.220 align:middle line:84% yeah, I can take an x j value, but I've 01:11:20.220 --> 01:11:22.500 align:middle line:84% got to be careful that I can stick it underneath. 01:11:22.500 --> 01:11:26.710 align:middle line:84% So, in particular, what do we know? 01:11:26.710 --> 01:11:34.410 align:middle line:84% Well, I can do anything from 1 to i minus 1 01:11:34.410 --> 01:11:37.800 align:middle line:84% because that's sort of the definition of xi. 01:11:37.800 --> 01:11:43.090 align:middle line:84% But, in particular, I can stack it on top. 01:11:43.090 --> 01:11:45.970 align:middle line:90% 01:11:45.970 --> 01:11:48.490 align:middle line:84% So one easy way to do this is I just array-- 01:11:48.490 --> 01:11:52.150 align:middle line:84% I iterate through the first i minus 1 elements of my array, 01:11:52.150 --> 01:11:53.830 align:middle line:84% and I just check my stacking condition 01:11:53.830 --> 01:11:55.480 align:middle line:84% for every single one of them relative 01:11:55.480 --> 01:11:59.830 align:middle line:84% to block j, so, in other words, that the width and the height-- 01:11:59.830 --> 01:12:02.080 align:middle line:84% or rather, the first and the second coordinate 01:12:02.080 --> 01:12:04.450 align:middle line:84% satisfy the strict inequalities that I need. 01:12:04.450 --> 01:12:06.910 align:middle line:84% I'm phrasing this sentence neutrally 01:12:06.910 --> 01:12:10.310 align:middle line:84% because I forget whether this is increasing or decreasing. 01:12:10.310 --> 01:12:11.530 align:middle line:90% But in any event-- 01:12:11.530 --> 01:12:12.290 align:middle line:90% so what do I do? 01:12:12.290 --> 01:12:15.070 align:middle line:84% I check all of the blocks that I could possibly 01:12:15.070 --> 01:12:17.035 align:middle line:84% stack from the index of the array perspective. 01:12:17.035 --> 01:12:18.910 align:middle line:84% I make sure that I could actually stack them, 01:12:18.910 --> 01:12:21.460 align:middle line:84% thanks to the size of the current block 01:12:21.460 --> 01:12:24.070 align:middle line:84% that I just decided to add to my stack. 01:12:24.070 --> 01:12:26.530 align:middle line:90% And I move recursively. 01:12:26.530 --> 01:12:27.260 align:middle line:90% OK. 01:12:27.260 --> 01:12:27.760 align:middle line:90% Right. 01:12:27.760 --> 01:12:30.010 align:middle line:84% So this is great because now we're 01:12:30.010 --> 01:12:31.870 align:middle line:84% in exactly the recursive scenario we wanted 01:12:31.870 --> 01:12:36.140 align:middle line:84% to be in, because x i only depends on x j, where 01:12:36.140 --> 01:12:37.630 align:middle line:90% j is smaller than i. 01:12:37.630 --> 01:12:40.780 align:middle line:84% And that is exactly our topological 01:12:40.780 --> 01:12:43.450 align:middle line:90% ordering that we need. 01:12:43.450 --> 01:12:47.260 align:middle line:84% If you do that on your homework, you get a minus n for large n. 01:12:47.260 --> 01:12:48.730 align:middle line:90% OK. 01:12:48.730 --> 01:12:50.920 align:middle line:90% Similarly, what's our base case? 01:12:50.920 --> 01:12:56.020 align:middle line:84% Well, obviously, if I only have one block, 01:12:56.020 --> 01:12:58.030 align:middle line:90% I might as well use it. 01:12:58.030 --> 01:13:03.190 align:middle line:84% So in that case, we have x1 is equal to v(1) our notation here 01:13:03.190 --> 01:13:05.380 align:middle line:90% like that. 01:13:05.380 --> 01:13:08.510 align:middle line:84% Our original one, we have to be a little bit careful because 01:13:08.510 --> 01:13:12.670 align:middle line:84% of the way that I've defined x, because x assumes that I've 01:13:12.670 --> 01:13:16.760 align:middle line:84% used a particular block, so I have to say, 01:13:16.760 --> 01:13:19.870 align:middle line:84% well, I might not have actually chosen the very last block 01:13:19.870 --> 01:13:21.880 align:middle line:90% as the one I want to keep. 01:13:21.880 --> 01:13:22.840 align:middle line:90% So I have to iterate. 01:13:22.840 --> 01:13:26.500 align:middle line:84% I can say that, really, my original 01:13:26.500 --> 01:13:27.927 align:middle line:90% is the max over i of x i. 01:13:27.927 --> 01:13:30.010 align:middle line:84% So one of these blocks has to be the block on top. 01:13:30.010 --> 01:13:32.177 align:middle line:84% I'm just going to iterate over all the possible ones 01:13:32.177 --> 01:13:33.490 align:middle line:90% and find it. 01:13:33.490 --> 01:13:38.740 align:middle line:84% And then our final thing to do is the runtime t. 01:13:38.740 --> 01:13:42.520 align:middle line:84% This one is mildly trickier than the previous runtimes 01:13:42.520 --> 01:13:45.370 align:middle line:84% that we've done so far in our example problem. 01:13:45.370 --> 01:13:50.000 align:middle line:84% In particular, how many subproblems are there? 01:13:50.000 --> 01:13:52.360 align:middle line:90% Well, there's n subproblems-- 01:13:52.360 --> 01:13:54.610 align:middle line:84% or I'll say order n because I'm always off by 1-- 01:13:54.610 --> 01:13:59.630 align:middle line:90% 01:13:59.630 --> 01:14:04.347 align:middle line:84% corresponding to each block in my stack here. 01:14:04.347 --> 01:14:05.930 align:middle line:84% But how much time does each subproblem 01:14:05.930 --> 01:14:08.540 align:middle line:84% take, at least the way that I've written it here? 01:14:08.540 --> 01:14:10.220 align:middle line:90% Well, what I have to do? 01:14:10.220 --> 01:14:12.500 align:middle line:84% I have to loop over all of the possible blocks 01:14:12.500 --> 01:14:16.290 align:middle line:84% and find the one that I can stack on top of 01:14:16.290 --> 01:14:17.310 align:middle line:90% and then take the max. 01:14:17.310 --> 01:14:22.480 align:middle line:84% So there's a loop here from 1 to i. i is upper bounded by n. 01:14:22.480 --> 01:14:27.280 align:middle line:84% So this is order n subproblems times order n 01:14:27.280 --> 01:14:32.510 align:middle line:90% work per subproblem. 01:14:32.510 --> 01:14:35.860 align:middle line:84% So at the end of the day, my algorithm 01:14:35.860 --> 01:14:38.700 align:middle line:84% is going to be order n squared time. 01:14:38.700 --> 01:14:39.720 align:middle line:90% And, of course, again-- 01:14:39.720 --> 01:14:42.450 align:middle line:84% I guess I promised it and then I didn't actually do it-- 01:14:42.450 --> 01:14:44.197 align:middle line:84% to actually implement this algorithm, 01:14:44.197 --> 01:14:46.030 align:middle line:84% there's sort of two different ways to do it. 01:14:46.030 --> 01:14:49.640 align:middle line:84% I could write a recursive call plus a table. 01:14:49.640 --> 01:14:51.990 align:middle line:84% The tables maybe initialized to a bunch of NaNs. 01:14:51.990 --> 01:14:54.630 align:middle line:84% And then I implement this function recursively. 01:14:54.630 --> 01:14:58.343 align:middle line:84% But before I do that, I say, if the table does not equal NaN, 01:14:58.343 --> 01:14:59.760 align:middle line:84% just return the value in the table 01:14:59.760 --> 01:15:03.030 align:middle line:84% and otherwise call this recursion. 01:15:03.030 --> 01:15:06.300 align:middle line:84% Or I can just have a four loop from 1 to n 01:15:06.300 --> 01:15:09.060 align:middle line:84% and build up the table one element at a time. 01:15:09.060 --> 01:15:11.010 align:middle line:84% And both of those are exactly the same 01:15:11.010 --> 01:15:13.550 align:middle line:90% from a runtime perspective. 01:15:13.550 --> 01:15:14.050 align:middle line:90% OK. 01:15:14.050 --> 01:15:15.800 align:middle line:84% So I think I've managed to watch that much 01:15:15.800 --> 01:15:18.160 align:middle line:84% more than my notes or the written solution, 01:15:18.160 --> 01:15:19.660 align:middle line:84% but the problem itself is actually 01:15:19.660 --> 01:15:20.490 align:middle line:90% pretty straightforward. 01:15:20.490 --> 01:15:22.720 align:middle line:84% So if you guys read through the answer plus some of-- 01:15:22.720 --> 01:15:24.762 align:middle line:84% I think, actually, the hard parts of this problem 01:15:24.762 --> 01:15:26.170 align:middle line:84% were not the dynamic programming, 01:15:26.170 --> 01:15:28.253 align:middle line:84% it was all the observations you need to get there. 01:15:28.253 --> 01:15:31.270 align:middle line:84% So that's why I spent a little more time there. 01:15:31.270 --> 01:15:31.870 align:middle line:90% OK. 01:15:31.870 --> 01:15:33.940 align:middle line:84% So, as usual, I haven't left myself enough time 01:15:33.940 --> 01:15:35.740 align:middle line:90% for the last problem. 01:15:35.740 --> 01:15:37.810 align:middle line:84% But we have a few minutes and that'll 01:15:37.810 --> 01:15:39.825 align:middle line:84% be sufficient to set up the parts. 01:15:39.825 --> 01:15:41.200 align:middle line:84% I actually found the last problem 01:15:41.200 --> 01:15:44.020 align:middle line:84% to be easier even though it technically is, sort of, 01:15:44.020 --> 01:15:46.000 align:middle line:90% two dynamic programs in one. 01:15:46.000 --> 01:15:48.380 align:middle line:84% So I think the logic is a little easier. 01:15:48.380 --> 01:15:49.240 align:middle line:90% OK. 01:15:49.240 --> 01:15:53.130 align:middle line:90% So 01:15:53.130 --> 01:15:55.603 align:middle line:84% AUDIENCE: Use the backboard [INAUDIBLE].. 01:15:55.603 --> 01:15:57.520 align:middle line:84% JUSTIN SOLOMON: I think this is the backboard. 01:15:57.520 --> 01:16:00.070 align:middle line:84% Yeah, I was just realizing that this room doesn't work 01:16:00.070 --> 01:16:02.680 align:middle line:90% the same way as the other one. 01:16:02.680 --> 01:16:03.880 align:middle line:90% Yeah, this is embarrassing. 01:16:03.880 --> 01:16:05.963 align:middle line:84% You know, I spent all day thinking about topology, 01:16:05.963 --> 01:16:10.770 align:middle line:84% and this is like a classic kind of problem in that universe. 01:16:10.770 --> 01:16:14.450 align:middle line:90% 01:16:14.450 --> 01:16:15.110 align:middle line:90% OK. 01:16:15.110 --> 01:16:17.120 align:middle line:84% Well, we'll just erase one board at a time, 01:16:17.120 --> 01:16:20.703 align:middle line:84% and I'll try not to write three feet wide this time. 01:16:20.703 --> 01:16:22.828 align:middle line:84% Oh, this is probably the one board I shouldn't use. 01:16:22.828 --> 01:16:26.040 align:middle line:90% 01:16:26.040 --> 01:16:29.060 align:middle line:84% I don't think I like this classroom. 01:16:29.060 --> 01:16:29.560 align:middle line:90% OK. 01:16:29.560 --> 01:16:36.360 align:middle line:84% So, right, in our final problem, we're given an n-by-n grid. 01:16:36.360 --> 01:16:40.980 align:middle line:84% And on our n-by-n grid, Princess Apple-- 01:16:40.980 --> 01:16:41.855 align:middle line:90% Banana-- 01:16:41.855 --> 01:16:42.480 align:middle line:90% AUDIENCE: Plum. 01:16:42.480 --> 01:16:42.840 align:middle line:90% JUSTIN SOLOMON: --Plum. 01:16:42.840 --> 01:16:43.560 align:middle line:90% Princess Plum. 01:16:43.560 --> 01:16:46.590 align:middle line:90% 01:16:46.590 --> 01:16:48.300 align:middle line:84% Right, so here's our basic setup. 01:16:48.300 --> 01:16:53.753 align:middle line:84% There's a big grid of stuff, or maybe a small grid 01:16:53.753 --> 01:16:55.170 align:middle line:84% because I don't feel like drawing. 01:16:55.170 --> 01:16:58.570 align:middle line:84% And every grid square can have one of three things. 01:16:58.570 --> 01:16:59.920 align:middle line:90% We can have a mushroom. 01:16:59.920 --> 01:17:01.350 align:middle line:90% We can have a tree. 01:17:01.350 --> 01:17:03.540 align:middle line:90% Or it can have nothing at all. 01:17:03.540 --> 01:17:09.180 align:middle line:84% And our princess starts here, and she goes-- 01:17:09.180 --> 01:17:11.490 align:middle line:90% she wants to go there. 01:17:11.490 --> 01:17:15.330 align:middle line:84% And moreover, there's a couple of things 01:17:15.330 --> 01:17:16.720 align:middle line:90% that are worth noting here. 01:17:16.720 --> 01:17:24.330 align:middle line:84% So, first of all, her path is quick, meaning 01:17:24.330 --> 01:17:35.600 align:middle line:84% that she can only traverse 2n minus 1 grid squares 01:17:35.600 --> 01:17:38.610 align:middle line:84% to get from one corner to the other. 01:17:38.610 --> 01:17:40.850 align:middle line:84% And, apparently, she's very into mushrooms, 01:17:40.850 --> 01:17:44.390 align:middle line:84% and she'd like to accumulate as many as possible 01:17:44.390 --> 01:17:45.320 align:middle line:90% along her path. 01:17:45.320 --> 01:17:46.640 align:middle line:90% That's the basic setup here. 01:17:46.640 --> 01:17:50.440 align:middle line:84% So she wants to get from the upper left to lower right. 01:17:50.440 --> 01:17:54.670 align:middle line:84% And, in order to do so, she wants to take a quick path. 01:17:54.670 --> 01:17:56.530 align:middle line:84% Her main priority is to be efficient. 01:17:56.530 --> 01:17:59.050 align:middle line:84% But among the different quick paths, 01:17:59.050 --> 01:18:01.270 align:middle line:84% she wants to pick up a lot of mushrooms. 01:18:01.270 --> 01:18:02.188 align:middle line:90% It's understandable. 01:18:02.188 --> 01:18:03.730 align:middle line:84% AUDIENCE: And not walk through trees. 01:18:03.730 --> 01:18:05.980 align:middle line:84% JUSTIN SOLOMON: And not only through trees, thank you. 01:18:05.980 --> 01:18:07.780 align:middle line:84% So maybe there's some grid squares 01:18:07.780 --> 01:18:09.863 align:middle line:84% that are marked with a tree, meaning that you just 01:18:09.863 --> 01:18:11.190 align:middle line:90% can't go there. 01:18:11.190 --> 01:18:13.230 align:middle line:90% That's a tree. 01:18:13.230 --> 01:18:15.190 align:middle line:90% OK. 01:18:15.190 --> 01:18:17.530 align:middle line:84% Right, so that's our basic setup here. 01:18:17.530 --> 01:18:18.480 align:middle line:90% But the problem does-- 01:18:18.480 --> 01:18:19.855 align:middle line:84% it takes a bit of a twist, right? 01:18:19.855 --> 01:18:22.410 align:middle line:84% It's not saying just could be the shortest path, which 01:18:22.410 --> 01:18:26.400 align:middle line:84% would be very much like the last kind of unit in 6.006. 01:18:26.400 --> 01:18:29.220 align:middle line:84% But rather, the question is, sort of, 01:18:29.220 --> 01:18:33.240 align:middle line:84% what is the number of paths that she can take from one side 01:18:33.240 --> 01:18:38.143 align:middle line:84% to the other and what is the maximum number of mushrooms, is 01:18:38.143 --> 01:18:39.810 align:middle line:84% roughly the question asking, or at least 01:18:39.810 --> 01:18:41.750 align:middle line:84% what I remember from reading it last night. 01:18:41.750 --> 01:18:44.832 align:middle line:84% AUDIENCE: The number of paths that maximizes the same number. 01:18:44.832 --> 01:18:46.040 align:middle line:90% JUSTIN SOLOMON: That's right. 01:18:46.040 --> 01:18:48.890 align:middle line:84% So she has to take the most number of mushrooms 01:18:48.890 --> 01:18:51.380 align:middle line:84% she can, but there may be more than one path that 01:18:51.380 --> 01:18:53.013 align:middle line:84% gets you there that is quick, that 01:18:53.013 --> 01:18:54.680 align:middle line:84% satisfies this condition, in which case, 01:18:54.680 --> 01:18:56.720 align:middle line:84% she wants the count of the total number of ways 01:18:56.720 --> 01:18:58.512 align:middle line:84% you could get from one corner to the other. 01:18:58.512 --> 01:18:59.460 align:middle line:90% Why, you might ask-- 01:18:59.460 --> 01:19:01.740 align:middle line:90% why not? 01:19:01.740 --> 01:19:02.240 align:middle line:90% OK. 01:19:02.240 --> 01:19:04.700 align:middle line:90% So, right. 01:19:04.700 --> 01:19:10.530 align:middle line:84% So, for instance, maybe there's a mushroom here. 01:19:10.530 --> 01:19:13.280 align:middle line:84% Now there's a quick path that gets her there 01:19:13.280 --> 01:19:14.720 align:middle line:90% and collects one mushroom. 01:19:14.720 --> 01:19:15.740 align:middle line:90% So there's exactly one. 01:19:15.740 --> 01:19:21.620 align:middle line:84% But maybe if there's a mushroom there, well, initially, 01:19:21.620 --> 01:19:24.230 align:middle line:84% it feels like maybe she could get two mushrooms. 01:19:24.230 --> 01:19:27.050 align:middle line:84% She could go there, go pick up the second mushroom, 01:19:27.050 --> 01:19:28.560 align:middle line:90% and get back. 01:19:28.560 --> 01:19:31.880 align:middle line:84% But we're going to see that this quick condition actually 01:19:31.880 --> 01:19:33.620 align:middle line:84% allows-- it doesn't allow you to do that. 01:19:33.620 --> 01:19:34.460 align:middle line:90% OK? 01:19:34.460 --> 01:19:37.520 align:middle line:84% So, in fact, it'll turn out that quick paths can only 01:19:37.520 --> 01:19:40.100 align:middle line:84% collect one mushroom in this 3-by-3 case, 01:19:40.100 --> 01:19:44.150 align:middle line:84% so there's at least two different paths. 01:19:44.150 --> 01:19:49.360 align:middle line:84% Well, there's 1, 2, 3 different ways 01:19:49.360 --> 01:19:52.890 align:middle line:84% that she could collect one mushroom and have a quick path. 01:19:52.890 --> 01:19:55.060 align:middle line:90% OK. 01:19:55.060 --> 01:19:57.280 align:middle line:84% So the first thing to notice is the instructions 01:19:57.280 --> 01:20:01.450 align:middle line:84% are a little bit sneaky by defining quick paths, 01:20:01.450 --> 01:20:03.880 align:middle line:84% basically, by giving her no slack at all. 01:20:03.880 --> 01:20:05.320 align:middle line:90% Right? 01:20:05.320 --> 01:20:08.280 align:middle line:90% And here's a basic observation. 01:20:08.280 --> 01:20:10.280 align:middle line:84% Notice that in order to give from the upper left 01:20:10.280 --> 01:20:11.947 align:middle line:84% to the bottom right, she's going to have 01:20:11.947 --> 01:20:13.390 align:middle line:90% to go down and to the right. 01:20:13.390 --> 01:20:14.800 align:middle line:90% Plausibly, she could also go up. 01:20:14.800 --> 01:20:19.752 align:middle line:84% She could try and go around a tree, but only plausibly. 01:20:19.752 --> 01:20:22.210 align:middle line:84% And, in particular, the question is how many times does she 01:20:22.210 --> 01:20:23.960 align:middle line:84% have to go down and how many times did she 01:20:23.960 --> 01:20:25.490 align:middle line:90% have to go to the right. 01:20:25.490 --> 01:20:28.230 align:middle line:84% Well, she has to get to the bottom of the grid. 01:20:28.230 --> 01:20:30.115 align:middle line:84% So she's on grid square number 1. 01:20:30.115 --> 01:20:32.240 align:middle line:84% She has to go down, in this case, at least two more 01:20:32.240 --> 01:20:34.730 align:middle line:84% times, so, in general, n minus 1 times. 01:20:34.730 --> 01:20:38.592 align:middle line:84% She has to go to the right n minus 1 times. 01:20:38.592 --> 01:20:39.550 align:middle line:90% So what does that mean? 01:20:39.550 --> 01:20:43.100 align:middle line:84% She has to make 2n minus 2 moves. 01:20:43.100 --> 01:20:44.447 align:middle line:90% And that's a lower bound, right? 01:20:44.447 --> 01:20:46.780 align:middle line:84% So if she goes up, she's going to have to go down again, 01:20:46.780 --> 01:20:48.120 align:middle line:84% so it's only going to make it bigger. 01:20:48.120 --> 01:20:48.770 align:middle line:90% Right? 01:20:48.770 --> 01:20:55.670 align:middle line:84% So at the very least, she has to do 2n minus 2 moves 01:20:55.670 --> 01:21:01.310 align:middle line:84% down and right to get from the upper left to the lower right. 01:21:01.310 --> 01:21:03.620 align:middle line:84% How many squares does she touch when she's doing that? 01:21:03.620 --> 01:21:05.040 align:middle line:90% This is a fence post problem. 01:21:05.040 --> 01:21:06.710 align:middle line:84% So she made 2n minus 2 moves, and she 01:21:06.710 --> 01:21:09.380 align:middle line:90% had a place where she started. 01:21:09.380 --> 01:21:13.070 align:middle line:84% That implies that just by moving down and to the right, 01:21:13.070 --> 01:21:17.150 align:middle line:90% she makes 2n minus 1 squares-- 01:21:17.150 --> 01:21:20.020 align:middle line:90% she touches, rather. 01:21:20.020 --> 01:21:22.460 align:middle line:90% So can she ever move up? 01:21:22.460 --> 01:21:23.060 align:middle line:90% No. 01:21:23.060 --> 01:21:24.710 align:middle line:90% Can she ever move to the left? 01:21:24.710 --> 01:21:25.947 align:middle line:90% No. 01:21:25.947 --> 01:21:28.405 align:middle line:84% And that, basically, is all you need to solve this problem. 01:21:28.405 --> 01:21:30.170 align:middle line:84% The rest of it's actually pretty easy. 01:21:30.170 --> 01:21:32.937 align:middle line:84% So the basic observation here is she can only move down 01:21:32.937 --> 01:21:35.270 align:middle line:84% and to the right because if she moved up or to the left, 01:21:35.270 --> 01:21:37.490 align:middle line:84% her path would no longer be called quick, 01:21:37.490 --> 01:21:38.880 align:middle line:90% and that would be a problem. 01:21:38.880 --> 01:21:41.750 align:middle line:84% Moreover, every path that moves down and to the right 01:21:41.750 --> 01:21:45.330 align:middle line:84% is a quick path, assuming she reaches their target 01:21:45.330 --> 01:21:46.980 align:middle line:90% and doesn't hit a tree. 01:21:46.980 --> 01:21:49.080 align:middle line:90% OK? 01:21:49.080 --> 01:21:50.460 align:middle line:90% So that's the basic observation. 01:21:50.460 --> 01:21:52.560 align:middle line:84% And notice that that already basically suggests-- 01:21:52.560 --> 01:21:54.253 align:middle line:84% it's, like, screaming out to you-- 01:21:54.253 --> 01:21:56.670 align:middle line:84% how to do dynamic programming because, literally, you have 01:21:56.670 --> 01:22:01.450 align:middle line:84% a table looking at you on the blackboard right now, 01:22:01.450 --> 01:22:05.530 align:middle line:84% and you have an ordering down and to the right that 01:22:05.530 --> 01:22:06.410 align:middle line:90% is acyclic. 01:22:06.410 --> 01:22:07.370 align:middle line:90% Yeah? 01:22:07.370 --> 01:22:07.870 align:middle line:90% OK. 01:22:07.870 --> 01:22:09.730 align:middle line:84% Have I slammed on the board enough times? 01:22:09.730 --> 01:22:11.350 align:middle line:84% The first time I taught at Stanford, 01:22:11.350 --> 01:22:14.620 align:middle line:84% I got negative course feedback that I had too much coffee 01:22:14.620 --> 01:22:18.070 align:middle line:84% and was slamming on the board a lot, apparently. 01:22:18.070 --> 01:22:21.050 align:middle line:84% I watched the video later, and, indeed, that was not wrong. 01:22:21.050 --> 01:22:22.180 align:middle line:90% OK. 01:22:22.180 --> 01:22:23.830 align:middle line:90% So, right. 01:22:23.830 --> 01:22:27.520 align:middle line:90% So, we're going to call k-- 01:22:27.520 --> 01:22:34.090 align:middle line:84% this is going to be the max mushrooms she 01:22:34.090 --> 01:22:36.550 align:middle line:84% can get going on the entire path from the upper left 01:22:36.550 --> 01:22:37.447 align:middle line:90% of the lower right. 01:22:37.447 --> 01:22:39.280 align:middle line:84% So we want to know the number of quick paths 01:22:39.280 --> 01:22:42.150 align:middle line:90% that can achieve this number k. 01:22:42.150 --> 01:22:42.650 align:middle line:90% OK. 01:22:42.650 --> 01:22:48.496 align:middle line:84% So let's do SRTBOT really fast because I've got four minutes-- 01:22:48.496 --> 01:22:51.150 align:middle line:84% actually, a tiny bit more than that because we started late. 01:22:51.150 --> 01:22:51.650 align:middle line:90% OK. 01:22:51.650 --> 01:22:55.300 align:middle line:90% 01:22:55.300 --> 01:22:57.700 align:middle line:84% Now, the kind of annoyance here is 01:22:57.700 --> 01:23:01.180 align:middle line:84% that there's two different numbers that we don't know. 01:23:01.180 --> 01:23:03.820 align:middle line:84% One of them is k, and the other is the number of paths. 01:23:03.820 --> 01:23:06.790 align:middle line:84% The problem didn't tell you how many mushrooms she can pick up. 01:23:06.790 --> 01:23:08.830 align:middle line:84% It does tell you that there's some path 01:23:08.830 --> 01:23:10.360 align:middle line:84% to get from the upper left to the bottom right, 01:23:10.360 --> 01:23:12.068 align:middle line:84% that there's not just like a row of trees 01:23:12.068 --> 01:23:17.660 align:middle line:84% somewhere, which I feel in my commute sometimes. 01:23:17.660 --> 01:23:21.740 align:middle line:84% But it doesn't tell you the number 01:23:21.740 --> 01:23:23.600 align:middle line:90% that she has to accomplish. 01:23:23.600 --> 01:23:25.890 align:middle line:84% And, initially, that's kind of annoying. 01:23:25.890 --> 01:23:27.680 align:middle line:84% So maybe the first thing that we do 01:23:27.680 --> 01:23:30.170 align:middle line:84% is just compute k, like, the maximum number 01:23:30.170 --> 01:23:34.660 align:middle line:84% of mushrooms that she can collect on any quick path. 01:23:34.660 --> 01:23:37.070 align:middle line:84% And then we go back and compute that other count. 01:23:37.070 --> 01:23:38.820 align:middle line:84% That would be one problem-solving approach 01:23:38.820 --> 01:23:41.750 align:middle line:84% that we could think about a little bit. 01:23:41.750 --> 01:23:50.065 align:middle line:84% So, in particular, let's define our k ij to be equal to-- 01:23:50.065 --> 01:23:51.940 align:middle line:84% well, we can generalize our problem slightly, 01:23:51.940 --> 01:23:54.250 align:middle line:84% and say what is the number of mushrooms 01:23:54.250 --> 01:23:57.340 align:middle line:84% that I can get on any kind of rectangle embedded inside 01:23:57.340 --> 01:23:59.260 align:middle line:90% of my full problem, right? 01:23:59.260 --> 01:24:04.540 align:middle line:84% So, in other words, this is the max number of mushrooms, 01:24:04.540 --> 01:24:14.987 align:middle line:84% or m's for short, on a quick path to ij. 01:24:14.987 --> 01:24:17.320 align:middle line:84% So, in other words, she always starts in the upper left, 01:24:17.320 --> 01:24:20.020 align:middle line:84% but now she stops at any other grid cell. 01:24:20.020 --> 01:24:20.520 align:middle line:90% OK? 01:24:20.520 --> 01:24:23.570 align:middle line:90% 01:24:23.570 --> 01:24:25.925 align:middle line:84% Because I'm running low on time-- 01:24:25.925 --> 01:24:28.050 align:middle line:84% no, I'm going to do this the way I want to do this. 01:24:28.050 --> 01:24:29.758 align:middle line:84% No, so we're just going to think about k. 01:24:29.758 --> 01:24:30.600 align:middle line:90% Yeah? 01:24:30.600 --> 01:24:34.620 align:middle line:84% So the question is could we compute just 01:24:34.620 --> 01:24:38.160 align:middle line:84% as value k, which certainly seems convenient. 01:24:38.160 --> 01:24:41.343 align:middle line:84% Princess Plum, she might as well know her enemy. 01:24:41.343 --> 01:24:43.260 align:middle line:84% She might as well know the number of mushrooms 01:24:43.260 --> 01:24:44.880 align:middle line:84% she's targeting, if she can get it. 01:24:44.880 --> 01:24:47.640 align:middle line:90% 01:24:47.640 --> 01:24:53.830 align:middle line:84% So how could we do this recursively? 01:24:53.830 --> 01:24:58.120 align:middle line:84% Well, she has to get to position ij. 01:24:58.120 --> 01:25:00.430 align:middle line:84% And from our argument up there, she 01:25:00.430 --> 01:25:04.640 align:middle line:84% has to get there by either coming from up or to the left, 01:25:04.640 --> 01:25:07.020 align:middle line:84% the way we've chosen to write down this problem. 01:25:07.020 --> 01:25:09.980 align:middle line:90% So what are our different cases? 01:25:09.980 --> 01:25:12.080 align:middle line:84% Well, first of all, if there's a tree, 01:25:12.080 --> 01:25:13.200 align:middle line:90% you can't do a damn thing. 01:25:13.200 --> 01:25:14.750 align:middle line:84% She shouldn't even be able to get there. 01:25:14.750 --> 01:25:16.490 align:middle line:84% And for convenience, we're going to find 01:25:16.490 --> 01:25:18.590 align:middle line:90% you can argue that it's 0. 01:25:18.590 --> 01:25:20.750 align:middle line:84% We're going to mark this with a special number, 01:25:20.750 --> 01:25:22.500 align:middle line:84% and we'll see that that makes our notation 01:25:22.500 --> 01:25:23.540 align:middle line:90% a little convenient. 01:25:23.540 --> 01:25:28.430 align:middle line:84% So one is if there exists a tree, 01:25:28.430 --> 01:25:32.723 align:middle line:84% then we're going to say k ij is minus infinity. 01:25:32.723 --> 01:25:34.640 align:middle line:84% Again, there's a philosophical question there. 01:25:34.640 --> 01:25:36.380 align:middle line:84% Does she get minus infinity mushrooms 01:25:36.380 --> 01:25:38.180 align:middle line:84% if she is standing on top of a tree? 01:25:38.180 --> 01:25:39.060 align:middle line:84% I don't know, because she shouldn't 01:25:39.060 --> 01:25:40.220 align:middle line:90% stand on top of a tree. 01:25:40.220 --> 01:25:42.500 align:middle line:84% But at least it's going to let us know that something 01:25:42.500 --> 01:25:44.720 align:middle line:84% went wrong in this grid square in the other parts 01:25:44.720 --> 01:25:46.130 align:middle line:90% of our recursion. 01:25:46.130 --> 01:25:48.320 align:middle line:90% OK? 01:25:48.320 --> 01:25:55.720 align:middle line:84% And otherwise, well, what are our different cases here? 01:25:55.720 --> 01:25:58.100 align:middle line:84% Well, she always picks up a mushroom if it's there. 01:25:58.100 --> 01:25:58.850 align:middle line:90% She might as well. 01:25:58.850 --> 01:26:00.370 align:middle line:90% She's maximizing. 01:26:00.370 --> 01:26:02.385 align:middle line:84% In fact, the problem even says that she's really 01:26:02.385 --> 01:26:03.010 align:middle line:90% into mushrooms. 01:26:03.010 --> 01:26:05.950 align:middle line:84% She collects them automatically, right? 01:26:05.950 --> 01:26:07.720 align:middle line:90% So what do we get? 01:26:07.720 --> 01:26:10.710 align:middle line:90% 01:26:10.710 --> 01:26:13.110 align:middle line:84% I use unnecessarily fancy notation. 01:26:13.110 --> 01:26:19.140 align:middle line:84% This is an indicator of whether there exists a mushroom 01:26:19.140 --> 01:26:27.030 align:middle line:84% at position ij, meaning this is a 1 if there is, 01:26:27.030 --> 01:26:29.280 align:middle line:90% and there's a 0 if there's not. 01:26:29.280 --> 01:26:32.790 align:middle line:84% Sometimes this is indicated with a 1 with a little subscript, 01:26:32.790 --> 01:26:34.830 align:middle line:90% but whatever. 01:26:34.830 --> 01:26:36.870 align:middle line:84% In addition to that, she might have picked up 01:26:36.870 --> 01:26:38.490 align:middle line:90% mushrooms along paths. 01:26:38.490 --> 01:26:41.580 align:middle line:84% And we know that her path to position ij either 01:26:41.580 --> 01:26:44.480 align:middle line:90% came from up or to the left. 01:26:44.480 --> 01:26:51.140 align:middle line:84% So, in other words, we know that she 01:26:51.140 --> 01:26:53.600 align:middle line:84% could have gotten the max from any path ending above her 01:26:53.600 --> 01:26:55.250 align:middle line:90% or any path to the left of her. 01:26:55.250 --> 01:27:00.380 align:middle line:84% So that's k i minus 1j, which, I guess, 01:27:00.380 --> 01:27:07.210 align:middle line:84% is to the left, and k ij minus 1, like that. 01:27:07.210 --> 01:27:11.620 align:middle line:84% And this can be used to fill in our whole table of k values. 01:27:11.620 --> 01:27:13.120 align:middle line:84% In fact, since I'm low on time, I'll 01:27:13.120 --> 01:27:18.650 align:middle line:84% let you do the TBOT for the remainder of this problem. 01:27:18.650 --> 01:27:21.395 align:middle line:84% Essentially, I think the key observation is this one. 01:27:21.395 --> 01:27:23.270 align:middle line:84% Obviously, when she starts in the upper left, 01:27:23.270 --> 01:27:24.620 align:middle line:84% she gets 0 mushrooms because she's not 01:27:24.620 --> 01:27:25.578 align:middle line:90% standing on top of one. 01:27:25.578 --> 01:27:27.750 align:middle line:90% The problem says that. 01:27:27.750 --> 01:27:30.360 align:middle line:84% And this allows us to fill in our whole table k. 01:27:30.360 --> 01:27:32.610 align:middle line:84% So, in particular, this gives us our enemy now. 01:27:32.610 --> 01:27:36.952 align:middle line:84% We now know how many mushrooms she should have 01:27:36.952 --> 01:27:38.160 align:middle line:90% at every step of her journey. 01:27:38.160 --> 01:27:39.660 align:middle line:84% In fact, it tells us a tiny bit more 01:27:39.660 --> 01:27:42.240 align:middle line:84% than that because it says if I'm at this grid 01:27:42.240 --> 01:27:46.020 align:middle line:84% sq-- at this particular grid square during my path, 01:27:46.020 --> 01:27:47.560 align:middle line:84% I should have this many mushrooms. 01:27:47.560 --> 01:27:49.950 align:middle line:84% If I didn't, then something went wrong. 01:27:49.950 --> 01:27:51.343 align:middle line:90% Yeah? 01:27:51.343 --> 01:27:53.010 align:middle line:84% So the way that the solution is written, 01:27:53.010 --> 01:27:55.272 align:middle line:84% they do two pieces of the recursion at once. 01:27:55.272 --> 01:27:57.480 align:middle line:84% You actually could have just solved for this k matrix 01:27:57.480 --> 01:27:59.550 align:middle line:84% first and then gone back and done the second half 01:27:59.550 --> 01:28:00.300 align:middle line:90% of this problem. 01:28:00.300 --> 01:28:02.770 align:middle line:90% And those are exactly the same. 01:28:02.770 --> 01:28:04.458 align:middle line:84% And when I was writing my solution, 01:28:04.458 --> 01:28:06.750 align:middle line:84% this is the way I thought about it, because, somehow, I 01:28:06.750 --> 01:28:07.980 align:middle line:84% kind of felt like she might as well know 01:28:07.980 --> 01:28:09.990 align:middle line:84% how many mushrooms she wants to collect before she starts 01:28:09.990 --> 01:28:10.615 align:middle line:90% counting paths. 01:28:10.615 --> 01:28:13.620 align:middle line:84% That's like a secondary question, you know. 01:28:13.620 --> 01:28:15.760 align:middle line:90% And so this is one way to do it. 01:28:15.760 --> 01:28:18.820 align:middle line:84% So in our remaining negative 2 minutes, 01:28:18.820 --> 01:28:20.920 align:middle line:84% let's think about the recursion for computing. 01:28:20.920 --> 01:28:24.600 align:middle line:84% Remember that we want to know the number of paths needed 01:28:24.600 --> 01:28:28.770 align:middle line:84% to collect that many mushrooms, the maximum number 01:28:28.770 --> 01:28:31.690 align:middle line:90% of mushrooms. 01:28:31.690 --> 01:28:34.300 align:middle line:84% Please let there not be a whole lot of stuff on this board. 01:28:34.300 --> 01:28:35.967 align:middle line:84% Ah, there's not any stuff on this board. 01:28:35.967 --> 01:28:36.860 align:middle line:90% That's great. 01:28:36.860 --> 01:28:38.320 align:middle line:90% OK. 01:28:38.320 --> 01:28:42.690 align:middle line:84% So, in particular, now I'm going to define a second thing 01:28:42.690 --> 01:28:45.360 align:middle line:84% that I also I'm going to do dynamic programming on. 01:28:45.360 --> 01:28:51.540 align:middle line:84% I'm going to say that x ij is equal to-- and I'm going 01:28:51.540 --> 01:28:55.270 align:middle line:84% to make it kind of a sneaky definition here, 01:28:55.270 --> 01:29:12.320 align:middle line:84% which is the number of quick paths that end at ij with-- 01:29:12.320 --> 01:29:15.930 align:middle line:84% now, let's anticipate our problem a little bit. 01:29:15.930 --> 01:29:18.677 align:middle line:84% So at the end of the day, we're going to do x of n comma n 01:29:18.677 --> 01:29:21.260 align:middle line:84% because she wants to end up all the way down and to the right. 01:29:21.260 --> 01:29:23.135 align:middle line:84% And how many mushrooms does she want to have, 01:29:23.135 --> 01:29:24.290 align:middle line:90% now that we know k? 01:29:24.290 --> 01:29:27.770 align:middle line:84% She wants to have k of n comma n mushrooms. 01:29:27.770 --> 01:29:31.100 align:middle line:84% Along the way, it would be kind of ambitious 01:29:31.100 --> 01:29:32.780 align:middle line:84% if she wanted to have k of n comma n 01:29:32.780 --> 01:29:35.120 align:middle line:90% mushrooms the entire path. 01:29:35.120 --> 01:29:37.970 align:middle line:84% But it would be slightly less ambitious to have 01:29:37.970 --> 01:29:42.080 align:middle line:84% k of ij mushrooms because, somehow, that's 01:29:42.080 --> 01:29:45.900 align:middle line:84% exactly what we just constructed in the previous thing 01:29:45.900 --> 01:29:48.290 align:middle line:90% where it was paths. 01:29:48.290 --> 01:29:50.102 align:middle line:84% Well, the last guy looks like a max. 01:29:50.102 --> 01:29:52.310 align:middle line:84% Now we're going to expect to see some plus signs here 01:29:52.310 --> 01:29:54.980 align:middle line:84% because we're adding up how many paths we have. 01:29:54.980 --> 01:29:56.000 align:middle line:90% OK? 01:29:56.000 --> 01:29:59.480 align:middle line:84% And now let's come up with a recursive rule for the array x, 01:29:59.480 --> 01:30:01.560 align:middle line:90% and then we'll call it a day. 01:30:01.560 --> 01:30:10.980 align:middle line:84% So, in particular, [INAUDIBLE] one, if there's a tree, 01:30:10.980 --> 01:30:12.770 align:middle line:90% how many paths are there? 01:30:12.770 --> 01:30:15.560 align:middle line:84% There are no paths, because I can't get there. 01:30:15.560 --> 01:30:19.730 align:middle line:90% So then ij equals 0. 01:30:19.730 --> 01:30:20.330 align:middle line:90% OK? 01:30:20.330 --> 01:30:23.450 align:middle line:90% Otherwise, there ain't a tree. 01:30:23.450 --> 01:30:27.770 align:middle line:84% And now I have to be a little careful, right? 01:30:27.770 --> 01:30:30.890 align:middle line:84% So I need to write this like a little piece of code. 01:30:30.890 --> 01:30:34.400 align:middle line:84% You could have written this as a giant max, instead, or a bunch 01:30:34.400 --> 01:30:37.380 align:middle line:90% of cases and whatever. 01:30:37.380 --> 01:30:39.770 align:middle line:84% So let's think about it like a piece of code. 01:30:39.770 --> 01:30:42.560 align:middle line:84% So, initially, I think there are no paths that 01:30:42.560 --> 01:30:44.030 align:middle line:90% get me k ij mushrooms. 01:30:44.030 --> 01:30:45.995 align:middle line:90% That's perfectly fine. 01:30:45.995 --> 01:30:47.370 align:middle line:84% And remember, we're going to keep 01:30:47.370 --> 01:30:48.745 align:middle line:84% applying the same piece of logic, 01:30:48.745 --> 01:30:51.990 align:middle line:84% which is that a path can only come from to the left and up. 01:30:51.990 --> 01:30:56.770 align:middle line:84% And let's think about those two cases. 01:30:56.770 --> 01:30:58.560 align:middle line:84% And by the way, we're going to use chi 01:30:58.560 --> 01:31:01.710 align:middle line:84% to equal this chi of stuff that we 01:31:01.710 --> 01:31:04.500 align:middle line:90% had in the previous expression. 01:31:04.500 --> 01:31:07.470 align:middle line:84% So chi is 1 if there's a mushroom at this place, 01:31:07.470 --> 01:31:09.610 align:middle line:90% and 0 if there is not. 01:31:09.610 --> 01:31:12.290 align:middle line:90% OK. 01:31:12.290 --> 01:31:15.650 align:middle line:84% So my path can come from the left or up. 01:31:15.650 --> 01:31:20.030 align:middle line:84% I know that it can't come from up if the number of mushrooms 01:31:20.030 --> 01:31:23.150 align:middle line:84% that I got from up plus, potentially, the one that I got 01:31:23.150 --> 01:31:25.460 align:middle line:84% here doesn't align with the number of mushrooms 01:31:25.460 --> 01:31:28.670 align:middle line:84% that I should have by the k ij standard 01:31:28.670 --> 01:31:31.100 align:middle line:90% that I have set for myself. 01:31:31.100 --> 01:31:34.325 align:middle line:84% So if I want to write that out in code, the way I do that is I 01:31:34.325 --> 01:31:37.910 align:middle line:90% would say, if k of-- 01:31:37.910 --> 01:31:40.217 align:middle line:84% so let's say I look to the left first. 01:31:40.217 --> 01:31:42.800 align:middle line:84% This is like, you know, look to your left, look to your right, 01:31:42.800 --> 01:31:46.160 align:middle line:84% one of you will pass this exam kind of scenario. 01:31:46.160 --> 01:31:49.730 align:middle line:84% And I potentially add a mushroom at my current position 01:31:49.730 --> 01:31:52.140 align:middle line:90% if there is one. 01:31:52.140 --> 01:31:55.568 align:middle line:84% If that is equal to k ij, well, what does that mean? 01:31:55.568 --> 01:31:57.360 align:middle line:84% That means that paths that went to the left 01:31:57.360 --> 01:31:59.910 align:middle line:84% were able to collect the number of mushrooms I need to get 01:31:59.910 --> 01:32:01.560 align:middle line:90% to the position I am now. 01:32:01.560 --> 01:32:08.700 align:middle line:84% So now I can add all of the different ways. 01:32:08.700 --> 01:32:14.940 align:middle line:84% Maybe I'll do a plus equals x of i minus 1j 01:32:14.940 --> 01:32:16.815 align:middle line:84% because any path that got to the previous guy 01:32:16.815 --> 01:32:18.607 align:middle line:84% and collected the right number of mushrooms 01:32:18.607 --> 01:32:21.050 align:middle line:84% can now reach me and get the right number of mushrooms. 01:32:21.050 --> 01:32:24.300 align:middle line:84% And similarly, I can look up and do exactly the same logic. 01:32:24.300 --> 01:32:33.040 align:middle line:84% So if k of ij minus 1 plus this number is equal to k ij, 01:32:33.040 --> 01:32:43.980 align:middle line:84% then x ij gets an additional number of paths, like that. 01:32:43.980 --> 01:32:46.770 align:middle line:84% And now I do think it's worth spending 8 seconds thinking 01:32:46.770 --> 01:32:50.040 align:middle line:84% about our base cases here because, initially, 01:32:50.040 --> 01:32:52.050 align:middle line:84% when I first saw this, I panicked a little bit 01:32:52.050 --> 01:32:54.217 align:middle line:84% because it kind of looks like this would just end up 01:32:54.217 --> 01:32:56.643 align:middle line:84% getting a bunch of 0's because I'm just adding 01:32:56.643 --> 01:32:57.810 align:middle line:90% values of x's to themselves. 01:32:57.810 --> 01:32:59.352 align:middle line:84% I don't have, like, a 1 plus anything 01:32:59.352 --> 01:33:02.593 align:middle line:84% anywhere, which is kind of weird if you think about it. 01:33:02.593 --> 01:33:04.760 align:middle line:84% So all of the reason why the positive numbers appear 01:33:04.760 --> 01:33:07.310 align:middle line:84% in this problem is from the base case, which is kind of cool, 01:33:07.310 --> 01:33:07.810 align:middle line:90% I think. 01:33:07.810 --> 01:33:09.810 align:middle line:84% This is like, I think, one of these things where 01:33:09.810 --> 01:33:12.020 align:middle line:84% if you anticipated a problem, then it's cool, 01:33:12.020 --> 01:33:13.415 align:middle line:84% and if you didn't anticipate the problem to begin with 01:33:13.415 --> 01:33:15.080 align:middle line:84% and you just wrote down these formulas, 01:33:15.080 --> 01:33:17.990 align:middle line:84% you probably wouldn't even think that it's interesting. 01:33:17.990 --> 01:33:21.420 align:middle line:84% But in any event, what is our base case? 01:33:21.420 --> 01:33:24.440 align:middle line:90% So, we'll do the B in SRTBOT. 01:33:24.440 --> 01:33:30.053 align:middle line:84% So, first of all, what is k of 1, 1? 01:33:30.053 --> 01:33:31.720 align:middle line:84% Remember, that's the number of mushrooms 01:33:31.720 --> 01:33:33.637 align:middle line:84% she can collect by starting at the left square 01:33:33.637 --> 01:33:34.890 align:middle line:90% and going nowhere. 01:33:34.890 --> 01:33:37.530 align:middle line:84% And that's 0 because the problem says there's 01:33:37.530 --> 01:33:40.430 align:middle line:90% no mushrooms in the upper left. 01:33:40.430 --> 01:33:43.012 align:middle line:90% What's x of 1, 1? 01:33:43.012 --> 01:33:44.720 align:middle line:84% Well, this is the number of paths from 1, 01:33:44.720 --> 01:33:49.570 align:middle line:84% 1 to itself that collects 0 mushrooms, so that's 1. 01:33:49.570 --> 01:33:50.530 align:middle line:90% OK. 01:33:50.530 --> 01:33:52.930 align:middle line:84% And I think that the rest of the SRTBOT table 01:33:52.930 --> 01:33:56.360 align:middle line:84% here isn't terribly difficult to fill in. 01:33:56.360 --> 01:33:58.370 align:middle line:84% So I noticed that in kind of a funny way, 01:33:58.370 --> 01:34:00.287 align:middle line:84% all of these recursive steps are just adding 1 01:34:00.287 --> 01:34:02.745 align:middle line:90% to itself a bunch of times. 01:34:02.745 --> 01:34:04.870 align:middle line:84% But, of course, the way you do that, the reason why 01:34:04.870 --> 01:34:06.040 align:middle line:84% you get a number that is interesting, 01:34:06.040 --> 01:34:08.123 align:middle line:84% is because of all these if statements and the fact 01:34:08.123 --> 01:34:10.090 align:middle line:84% that you can add two different pluses coming 01:34:10.090 --> 01:34:11.870 align:middle line:90% from two different sources. 01:34:11.870 --> 01:34:12.430 align:middle line:90% OK. 01:34:12.430 --> 01:34:13.990 align:middle line:84% So I actually do encourage you guys 01:34:13.990 --> 01:34:16.540 align:middle line:84% to look at the code in the problem solution 01:34:16.540 --> 01:34:18.580 align:middle line:84% because I think it's a nice example of taking 01:34:18.580 --> 01:34:20.920 align:middle line:84% this recursive formula and then unrolling it into, 01:34:20.920 --> 01:34:22.802 align:middle line:90% like, iterating over a table. 01:34:22.802 --> 01:34:25.010 align:middle line:84% And that's a useful skill that I intended to do today 01:34:25.010 --> 01:34:27.645 align:middle line:84% and then didn't actually do very carefully. 01:34:27.645 --> 01:34:29.770 align:middle line:84% But with that, as usual, we've gone over time here. 01:34:29.770 --> 01:34:31.240 align:middle line:90% So we'll call it for the day. 01:34:31.240 --> 01:34:34.720 align:middle line:84% And I will see you guys when I see you guys. 01:34:34.720 --> 01:34:36.420 align:middle line:90% All right. 01:34:36.420 --> 01:34:41.000 align:middle line:90%