WEBVTT 00:00:00.000 --> 00:00:02.420 align:middle line:90% [SQUEAKING] 00:00:02.420 --> 00:00:04.356 align:middle line:90% [RUSTLING] 00:00:04.356 --> 00:00:06.776 align:middle line:90% [CLICKING] 00:00:06.776 --> 00:00:13.560 align:middle line:90% 00:00:13.560 --> 00:00:15.510 align:middle line:84% JUSTIN SOLOMON: So today, we're going 00:00:15.510 --> 00:00:19.980 align:middle line:84% to continue in our discussion of dynamic programming. 00:00:19.980 --> 00:00:23.070 align:middle line:84% I actually found this set of problem session problems 00:00:23.070 --> 00:00:26.610 align:middle line:84% to be easier than the previous one. 00:00:26.610 --> 00:00:29.190 align:middle line:84% There's a funny thing, which is we 00:00:29.190 --> 00:00:32.820 align:middle line:84% learned in class about pseudo polynomial time style 00:00:32.820 --> 00:00:34.470 align:middle line:90% dynamic programs. 00:00:34.470 --> 00:00:38.220 align:middle line:84% Somehow, that language is a little bit liberating, 00:00:38.220 --> 00:00:40.650 align:middle line:84% in the sense that you're using parameters that you really 00:00:40.650 --> 00:00:44.160 align:middle line:84% shouldn't, when it comes to the runtime of your algorithm. 00:00:44.160 --> 00:00:46.770 align:middle line:84% Well, I suppose we should, in the sense that it's allowed, 00:00:46.770 --> 00:00:49.230 align:middle line:84% if you call your algorithm pseudo polynomial time. 00:00:49.230 --> 00:00:50.950 align:middle line:84% But it somehow makes it a little easier 00:00:50.950 --> 00:00:52.950 align:middle line:84% to formulate your dynamic programming algorithm, 00:00:52.950 --> 00:00:56.220 align:middle line:84% because all the numbers are staring you right in the face. 00:00:56.220 --> 00:00:58.890 align:middle line:84% You don't have to be so careful about what's fair game 00:00:58.890 --> 00:01:02.910 align:middle line:84% and what's not, when you post your algorithm so long as it's 00:01:02.910 --> 00:01:06.460 align:middle line:84% efficient in the values that you care about. 00:01:06.460 --> 00:01:10.130 align:middle line:84% And so today's problem session has five problems squeezed 00:01:10.130 --> 00:01:11.722 align:middle line:90% instead of the usual four. 00:01:11.722 --> 00:01:13.680 align:middle line:84% We'll see how far we get, seeing that I usually 00:01:13.680 --> 00:01:15.157 align:middle line:90% talk too much anyway. 00:01:15.157 --> 00:01:16.740 align:middle line:84% But I'll try to stay on schedule here, 00:01:16.740 --> 00:01:19.710 align:middle line:90% and we'll see how well we do. 00:01:19.710 --> 00:01:22.115 align:middle line:84% Any questions from our students about dynamic programming 00:01:22.115 --> 00:01:23.240 align:middle line:90% before we get started here? 00:01:23.240 --> 00:01:25.170 align:middle line:84% AUDIENCE: You can cut one, if you want. 00:01:25.170 --> 00:01:26.462 align:middle line:90% JUSTIN SOLOMON: We can cut one? 00:01:26.462 --> 00:01:29.220 align:middle line:84% Oh, I will gladly cut one if I run out of time. 00:01:29.220 --> 00:01:30.220 align:middle line:90% Yeah. 00:01:30.220 --> 00:01:33.870 align:middle line:84% OK, so without further ado, let's 00:01:33.870 --> 00:01:39.270 align:middle line:84% get started with coin-crafting, which is problem 9-1 here. 00:01:39.270 --> 00:01:42.510 align:middle line:84% So I suppose it should be Ceal Naffrey 00:01:42.510 --> 00:01:48.640 align:middle line:84% if I were to work through my splinterism properly here. 00:01:48.640 --> 00:01:50.400 align:middle line:84% In any event, we have a thief who's 00:01:50.400 --> 00:01:53.400 align:middle line:84% in desperate need of money, as with many thieves, or else, 00:01:53.400 --> 00:01:56.580 align:middle line:84% of course, they wouldn't resort to the world of prime. 00:01:56.580 --> 00:02:03.090 align:middle line:84% And Ceal Naffrey here has n identical coins. 00:02:03.090 --> 00:02:08.328 align:middle line:90% 00:02:08.328 --> 00:02:10.120 align:middle line:84% I've been very self-conscious about the way 00:02:10.120 --> 00:02:12.520 align:middle line:84% that I write the letter I, ever since Eric pointed it out, 00:02:12.520 --> 00:02:13.645 align:middle line:90% and it's only gotten worse. 00:02:13.645 --> 00:02:16.750 align:middle line:84% Now it's inconsistent and hard to read. 00:02:16.750 --> 00:02:21.400 align:middle line:84% But in any event, so we have n identical coins. 00:02:21.400 --> 00:02:24.980 align:middle line:84% And of course, these coins have very distinctive markings. 00:02:24.980 --> 00:02:27.550 align:middle line:84% And so we can't possibly run away with them 00:02:27.550 --> 00:02:30.190 align:middle line:84% as is, because if you take them to your standard jeweler, 00:02:30.190 --> 00:02:32.980 align:middle line:84% they'll immediately recognize that these markings are 00:02:32.980 --> 00:02:33.970 align:middle line:90% bad and stolen. 00:02:33.970 --> 00:02:34.990 align:middle line:90% And that's not so good. 00:02:34.990 --> 00:02:40.690 align:middle line:84% So instead, we can melt these coins into other objects. 00:02:40.690 --> 00:02:46.930 align:middle line:84% So our sneaky thief here has identified a potential buyer. 00:02:46.930 --> 00:02:50.300 align:middle line:84% And the buyer has a few criteria here. 00:02:50.300 --> 00:02:59.002 align:middle line:84% So we have a buyer, and the buyer has a very strange value 00:02:59.002 --> 00:03:00.460 align:middle line:84% system thing, that apparently, it's 00:03:00.460 --> 00:03:04.790 align:middle line:84% easy to take coins and make them into other things. 00:03:04.790 --> 00:03:07.060 align:middle line:84% But in any event, the buyer, what they care about 00:03:07.060 --> 00:03:09.610 align:middle line:84% is not the fact that the coins are made of gold, 00:03:09.610 --> 00:03:13.180 align:middle line:84% but rather that they like particular objects better 00:03:13.180 --> 00:03:16.000 align:middle line:84% than others made out of said gold. 00:03:16.000 --> 00:03:18.880 align:middle line:84% So in particular, they have a different rate 00:03:18.880 --> 00:03:22.690 align:middle line:84% for each object, a different price they're willing to pay. 00:03:22.690 --> 00:03:31.230 align:middle line:84% And so they have a list of n objects 00:03:31.230 --> 00:03:33.360 align:middle line:90% that they're interested in. 00:03:33.360 --> 00:03:40.060 align:middle line:84% And each one is associated with two things of n objects. 00:03:40.060 --> 00:03:42.003 align:middle line:90% They have a price-- 00:03:42.003 --> 00:03:43.920 align:middle line:84% so the amount that the buyer is willing to pay 00:03:43.920 --> 00:03:46.950 align:middle line:84% for that object, which, again, is not just the weight in gold, 00:03:46.950 --> 00:03:48.600 align:middle line:90% for some reason. 00:03:48.600 --> 00:03:53.280 align:middle line:84% There's a value added tax in this universe. 00:03:53.280 --> 00:03:58.594 align:middle line:84% And it takes a different number of coins to manufacture. 00:03:58.594 --> 00:03:59.500 align:middle line:90% Right? 00:03:59.500 --> 00:04:03.990 align:middle line:84% So maybe I can make a golden chocolate fountain, 00:04:03.990 --> 00:04:05.370 align:middle line:90% and that takes 10 coins. 00:04:05.370 --> 00:04:06.620 align:middle line:90% But I don't want two of those. 00:04:06.620 --> 00:04:08.745 align:middle line:84% So if I make that, then the next thing I have to do 00:04:08.745 --> 00:04:12.935 align:middle line:84% is a figurine of Eric and Jason to put alongside it. 00:04:12.935 --> 00:04:14.310 align:middle line:84% And having more than one of those 00:04:14.310 --> 00:04:16.410 align:middle line:90% would also be creepy and weird. 00:04:16.410 --> 00:04:18.959 align:middle line:84% So I can only make one of each object. 00:04:18.959 --> 00:04:22.355 align:middle line:84% And of course, my goal here is I have n coins. 00:04:22.355 --> 00:04:23.730 align:middle line:84% By the way, the fact that there's 00:04:23.730 --> 00:04:28.007 align:middle line:84% n coins and n objects for the buyer doesn't really matter. 00:04:28.007 --> 00:04:29.340 align:middle line:90% I mean, it will for the runtime. 00:04:29.340 --> 00:04:32.070 align:middle line:84% But you could imagine this being n and m. 00:04:32.070 --> 00:04:35.378 align:middle line:84% So I wouldn't be too hung up on that. 00:04:35.378 --> 00:04:37.170 align:middle line:84% And what you're trying to do is, of course, 00:04:37.170 --> 00:04:40.530 align:middle line:84% maximize your revenue, subject to the constraints 00:04:40.530 --> 00:04:44.360 align:middle line:84% that you have n coins, and you can't make 00:04:44.360 --> 00:04:46.190 align:middle line:90% two objects that are the same. 00:04:46.190 --> 00:04:50.020 align:middle line:84% Hopefully, I've captured the essence of our problem OK. 00:04:50.020 --> 00:04:50.930 align:middle line:90% OK, fabulous. 00:04:50.930 --> 00:04:57.440 align:middle line:84% So as with all of our dynamic programming problems in 6006, 00:04:57.440 --> 00:05:00.860 align:middle line:84% we have a paradigm for how to approach them, 00:05:00.860 --> 00:05:04.100 align:middle line:84% which has a cute acronym, which is SRTBOT 00:05:04.100 --> 00:05:07.730 align:middle line:84% And I think SRTBOT is a totally relevant and straightforward 00:05:07.730 --> 00:05:10.370 align:middle line:90% approach to this problem here. 00:05:10.370 --> 00:05:12.740 align:middle line:84% Yeah, so in particular, let's give ourselves 00:05:12.740 --> 00:05:14.730 align:middle line:90% a bit of notation. 00:05:14.730 --> 00:05:17.900 align:middle line:84% So we're going to number our objects between 1 and n, 00:05:17.900 --> 00:05:19.440 align:middle line:90% just for convenience. 00:05:19.440 --> 00:05:27.410 align:middle line:84% So we'll say that Pi is the price of object i. 00:05:27.410 --> 00:05:30.240 align:middle line:90% 00:05:30.240 --> 00:05:30.740 align:middle line:90% OK. 00:05:30.740 --> 00:05:36.800 align:middle line:84% And we'll say that Ki is what the problem calls 00:05:36.800 --> 00:05:39.840 align:middle line:90% the melting number. 00:05:39.840 --> 00:05:41.840 align:middle line:84% In other words, if I want to make object i, 00:05:41.840 --> 00:05:43.548 align:middle line:84% this is the amount of coins that I'd have 00:05:43.548 --> 00:05:45.615 align:middle line:90% to melt to make that object. 00:05:45.615 --> 00:05:46.250 align:middle line:90% OK? 00:05:46.250 --> 00:05:49.240 align:middle line:90% So just a tiny bit of notation. 00:05:49.240 --> 00:05:50.710 align:middle line:84% And in general, so OK, what do we 00:05:50.710 --> 00:05:55.720 align:middle line:84% do when we formulate our dynamic programming problems? 00:05:55.720 --> 00:05:58.430 align:middle line:84% Some problems we could solve that are smaller. 00:05:58.430 --> 00:06:01.220 align:middle line:84% And when we compose them all together, 00:06:01.220 --> 00:06:03.500 align:middle line:84% we get the final solution to our problem. 00:06:03.500 --> 00:06:07.330 align:middle line:84% And this particular problem, involving manufacturing objects 00:06:07.330 --> 00:06:10.810 align:middle line:84% out of coins, I think is a really classic one, when it 00:06:10.810 --> 00:06:12.190 align:middle line:90% comes to dynamic programming. 00:06:12.190 --> 00:06:14.500 align:middle line:84% This is the sort of thing where someday, 00:06:14.500 --> 00:06:16.990 align:middle line:84% when you're trying to pay for your tuition 00:06:16.990 --> 00:06:19.053 align:middle line:84% by doing these hacker contests online, 00:06:19.053 --> 00:06:21.220 align:middle line:84% this is the sort of thing that comes up all the time 00:06:21.220 --> 00:06:23.830 align:middle line:90% in that universe, right? 00:06:23.830 --> 00:06:28.865 align:middle line:84% So in particular, the two variables here, 00:06:28.865 --> 00:06:32.150 align:middle line:84% when I make a new object, is what object did I make? 00:06:32.150 --> 00:06:34.890 align:middle line:84% And how many coins did I spend when I did that? 00:06:34.890 --> 00:06:36.710 align:middle line:84% So those are the two natural parameters 00:06:36.710 --> 00:06:39.960 align:middle line:84% to use, when I solve my dynamic programming problem. 00:06:39.960 --> 00:06:40.460 align:middle line:90% Yeah. 00:06:40.460 --> 00:06:42.800 align:middle line:84% And of course, it's going to be recursive, in the sense 00:06:42.800 --> 00:06:47.590 align:middle line:84% that I can either choose to make object i or not. 00:06:47.590 --> 00:06:50.420 align:middle line:84% And it doesn't matter what order I make my objects in 00:06:50.420 --> 00:06:52.430 align:middle line:84% or similarly, what order I spend my coins in, 00:06:52.430 --> 00:06:54.260 align:middle line:84% which is usually a nice property to have 00:06:54.260 --> 00:06:56.630 align:middle line:84% in a dynamic programming universe. 00:06:56.630 --> 00:07:02.780 align:middle line:84% So in particular-- oh, this thing is my nemesis. 00:07:02.780 --> 00:07:05.696 align:middle line:90% This is front. 00:07:05.696 --> 00:07:07.322 align:middle line:84% I think this class is particularly 00:07:07.322 --> 00:07:09.780 align:middle line:84% tough for short people, because it's moving up and down all 00:07:09.780 --> 00:07:10.540 align:middle line:90% the time. 00:07:10.540 --> 00:07:16.950 align:middle line:84% OK, so given our observation here, if we're doing SRTBOT, 00:07:16.950 --> 00:07:19.370 align:middle line:90% so what's our S again? 00:07:19.370 --> 00:07:20.370 align:middle line:90% Let me ask myself that-- 00:07:20.370 --> 00:07:21.090 align:middle line:90% Sub-problems. 00:07:21.090 --> 00:07:23.790 align:middle line:90% Thank you, Professor Demaine. 00:07:23.790 --> 00:07:26.800 align:middle line:84% Then essentially, what we want to do, 00:07:26.800 --> 00:07:29.790 align:middle line:84% based on what I argued verbally, is maybe 00:07:29.790 --> 00:07:31.710 align:middle line:84% define our variable x i, j the thing 00:07:31.710 --> 00:07:44.440 align:middle line:84% we're going to compute, to be the revenue from using i coins 00:07:44.440 --> 00:07:47.310 align:middle line:90% and objects 1 to j. 00:07:47.310 --> 00:07:52.930 align:middle line:90% 00:07:52.930 --> 00:07:53.620 align:middle line:90% OK. 00:07:53.620 --> 00:07:56.350 align:middle line:84% So in other words, I have i coins left in the bank, 00:07:56.350 --> 00:07:58.793 align:middle line:84% and I'm only allowed to use the first j objects. 00:07:58.793 --> 00:08:01.210 align:middle line:84% And we can already see that this is kind of a sensible way 00:08:01.210 --> 00:08:03.100 align:middle line:84% to approach this dynamic programming 00:08:03.100 --> 00:08:05.197 align:middle line:84% problem, in the sense that there's 00:08:05.197 --> 00:08:06.280 align:middle line:90% an obvious recursion here. 00:08:06.280 --> 00:08:07.405 align:middle line:90% I choose to make an object. 00:08:07.405 --> 00:08:09.020 align:middle line:90% I have fewer coins. 00:08:09.020 --> 00:08:13.900 align:middle line:84% And I can sort of imagine there being a topological order, 00:08:13.900 --> 00:08:16.720 align:middle line:84% in the sense that I could first decide about object 1, 00:08:16.720 --> 00:08:19.820 align:middle line:84% and then object 2, and object 3, and so on, or vice versa, 00:08:19.820 --> 00:08:23.620 align:middle line:84% depending on whether you're a prefix or suffix kind of guy-- 00:08:23.620 --> 00:08:25.330 align:middle line:90% which I still get backward. 00:08:25.330 --> 00:08:27.900 align:middle line:84% But the good news is that it doesn't really matter. 00:08:27.900 --> 00:08:30.190 align:middle line:84% What matters is formulating the equation. 00:08:30.190 --> 00:08:33.880 align:middle line:84% OK, any questions about our definition of the thing 00:08:33.880 --> 00:08:37.220 align:middle line:84% that we're going to chase after here? 00:08:37.220 --> 00:08:39.789 align:middle line:90% Fabulous. 00:08:39.789 --> 00:08:48.020 align:middle line:90% Ah-- OK, right. 00:08:48.020 --> 00:08:51.440 align:middle line:90% So let's continue SRTBOT. 00:08:51.440 --> 00:08:54.590 align:middle line:84% So our next piece of our puzzle here 00:08:54.590 --> 00:08:57.450 align:middle line:84% is the R. I believe R stands for recursion. 00:08:57.450 --> 00:08:58.970 align:middle line:84% This is a new acronym for me, too. 00:08:58.970 --> 00:09:00.470 align:middle line:90% Ope, no, Relate. 00:09:00.470 --> 00:09:01.860 align:middle line:84% But it might as well be Recursion 00:09:01.860 --> 00:09:04.430 align:middle line:90% for most of these problems. 00:09:04.430 --> 00:09:07.460 align:middle line:84% Right, so the basic relationship here is that, of course, 00:09:07.460 --> 00:09:13.430 align:middle line:84% I can either use object j, or I can not use object j. 00:09:13.430 --> 00:09:17.240 align:middle line:84% And in both of those cases, If j is the very last guy 00:09:17.240 --> 00:09:19.190 align:middle line:84% that I'm going to consider, that'll 00:09:19.190 --> 00:09:21.830 align:middle line:84% be a totally reasonable recursive rule, right? 00:09:21.830 --> 00:09:25.885 align:middle line:84% So in particular, I have that xi, 00:09:25.885 --> 00:09:31.250 align:middle line:84% j essentially can take one of two values. 00:09:31.250 --> 00:09:34.880 align:middle line:84% That's a parenthesis, in case you're wondering. 00:09:34.880 --> 00:09:38.580 align:middle line:84% And of course, you're trying to maximize your revenue. 00:09:38.580 --> 00:09:40.260 align:middle line:90% So let's do that, OK? 00:09:40.260 --> 00:09:49.537 align:middle line:84% So we have two potential options. 00:09:49.537 --> 00:09:50.870 align:middle line:90% But we have to be a bit careful. 00:09:50.870 --> 00:09:53.570 align:middle line:84% Is there a case where I can't make object j? 00:09:53.570 --> 00:09:56.270 align:middle line:90% 00:09:56.270 --> 00:09:59.567 align:middle line:84% Yes, class, there is, which is the case where 00:09:59.567 --> 00:10:01.650 align:middle line:84% I don't have enough coins left in the bank, right? 00:10:01.650 --> 00:10:03.770 align:middle line:84% So I want to make that really expensive fountain, 00:10:03.770 --> 00:10:04.850 align:middle line:90% but I only have one coin. 00:10:04.850 --> 00:10:07.100 align:middle line:90% Then I'm out of luck, yeah? 00:10:07.100 --> 00:10:09.310 align:middle line:90% So let's do these two cases. 00:10:09.310 --> 00:10:21.230 align:middle line:84% So first, if-- oops, I got my cases backward. 00:10:21.230 --> 00:10:22.230 align:middle line:90% That's OK. 00:10:22.230 --> 00:10:22.730 align:middle line:90% Right. 00:10:22.730 --> 00:10:26.810 align:middle line:84% So let's say that I choose not to make object j. 00:10:26.810 --> 00:10:28.120 align:middle line:90% OK, so what does that mean? 00:10:28.120 --> 00:10:29.890 align:middle line:90% So did I spend any coins? 00:10:29.890 --> 00:10:30.710 align:middle line:90% No. 00:10:30.710 --> 00:10:33.290 align:middle line:84% And moreover, what is my maximum profit? 00:10:33.290 --> 00:10:35.540 align:middle line:84% Well, it's going to be the same as the maximum profit, 00:10:35.540 --> 00:10:38.210 align:middle line:84% using objects 1 through j minus 1, 00:10:38.210 --> 00:10:39.500 align:middle line:90% because I didn't use object j. 00:10:39.500 --> 00:10:40.000 align:middle line:90% Yeah? 00:10:40.000 --> 00:10:42.200 align:middle line:84% So in particular, that would be x. 00:10:42.200 --> 00:10:45.450 align:middle line:90% 00:10:45.450 --> 00:10:47.220 align:middle line:84% Let's see, I got it backward in my notes, 00:10:47.220 --> 00:10:50.350 align:middle line:84% so we're going to do it live, like that. 00:10:50.350 --> 00:10:51.610 align:middle line:90% OK? 00:10:51.610 --> 00:10:55.770 align:middle line:84% And otherwise, let's say that I did choose to make object j. 00:10:55.770 --> 00:10:56.710 align:middle line:90% Well, what happened? 00:10:56.710 --> 00:11:00.160 align:middle line:84% So I did get some revenue now, right? 00:11:00.160 --> 00:11:03.690 align:middle line:84% Man, what on earth did I write on these notes? 00:11:03.690 --> 00:11:07.860 align:middle line:84% So I get the price of objects j here as my revenue. 00:11:07.860 --> 00:11:12.490 align:middle line:84% But I spent some coins in the process. 00:11:12.490 --> 00:11:18.780 align:middle line:84% So I have i minus K sub i, which is the number of coins. 00:11:18.780 --> 00:11:19.280 align:middle line:90% What's that? 00:11:19.280 --> 00:11:20.160 align:middle line:90% AUDIENCE: K sub j. 00:11:20.160 --> 00:11:22.805 align:middle line:84% JUSTIN SOLOMON: Oh, thank you-- sorry, K sub j. 00:11:22.805 --> 00:11:24.930 align:middle line:84% That's why we should be consistent with our indices 00:11:24.930 --> 00:11:28.130 align:middle line:90% when we write these things down. 00:11:28.130 --> 00:11:33.470 align:middle line:84% So I spent K sub j coins making this thing, object j. 00:11:33.470 --> 00:11:36.663 align:middle line:84% And moreover, I can still choose to make 00:11:36.663 --> 00:11:37.830 align:middle line:90% any of the previous objects. 00:11:37.830 --> 00:11:40.580 align:middle line:90% So it's still just j minus 1. 00:11:40.580 --> 00:11:44.290 align:middle line:84% But I have to be careful, because I can't always do this. 00:11:44.290 --> 00:11:48.220 align:middle line:84% In particular, this had better be a positive number for n, 00:11:48.220 --> 00:11:49.910 align:middle line:84% or at least a non-negative number. 00:11:49.910 --> 00:11:52.420 align:middle line:84% Because if I end up with a negative number of coins, 00:11:52.420 --> 00:11:54.910 align:middle line:84% well, that that's not a physical universe 00:11:54.910 --> 00:11:56.900 align:middle line:90% that I choose to be in. 00:11:56.900 --> 00:12:00.550 align:middle line:84% So in particular, what we need, in some sense, 00:12:00.550 --> 00:12:03.190 align:middle line:84% is i minus k minus j, and k and j 00:12:03.190 --> 00:12:05.990 align:middle line:84% to be greater than or equal to 0. 00:12:05.990 --> 00:12:08.975 align:middle line:84% Or equivalently, i is greater than or equal to K sub j. 00:12:08.975 --> 00:12:11.570 align:middle line:84% I think you guys could all do that one at home. 00:12:11.570 --> 00:12:13.310 align:middle line:90% OK, and this is our recursion. 00:12:13.310 --> 00:12:15.518 align:middle line:84% Hopefully, I've gotten it right, because it disagrees 00:12:15.518 --> 00:12:18.590 align:middle line:84% with the crazy thing I wrote in my notes at 1:00 AM yesterday. 00:12:18.590 --> 00:12:20.520 align:middle line:84% But I think it's pretty straightforward. 00:12:20.520 --> 00:12:23.330 align:middle line:84% Essentially, either I can choose to use the last object, 00:12:23.330 --> 00:12:25.160 align:middle line:90% or I choose not to. 00:12:25.160 --> 00:12:27.470 align:middle line:84% And either one of those, of course, 00:12:27.470 --> 00:12:29.930 align:middle line:84% decrements j, because that's the index 00:12:29.930 --> 00:12:31.670 align:middle line:90% of the object I'm considering. 00:12:31.670 --> 00:12:34.975 align:middle line:84% And I either account for the price, but have to pay in gold, 00:12:34.975 --> 00:12:36.350 align:middle line:84% or I don't account for the price. 00:12:36.350 --> 00:12:39.430 align:middle line:84% So implicitly, there's a 0, and I don't have to pay in gold. 00:12:39.430 --> 00:12:41.300 align:middle line:90% OK, good. 00:12:41.300 --> 00:12:43.400 align:middle line:84% All right, so let's continue with SRTBOT. 00:12:43.400 --> 00:12:46.575 align:middle line:84% We might, later in the session, relax 00:12:46.575 --> 00:12:48.200 align:middle line:84% going through every one of these steps, 00:12:48.200 --> 00:12:49.992 align:middle line:84% because a lot of the arguments are similar. 00:12:49.992 --> 00:12:52.490 align:middle line:84% But for now, we'll do one or two carefully. 00:12:52.490 --> 00:12:56.060 align:middle line:84% So T, I believe, stands for Topological order. 00:12:56.060 --> 00:12:57.980 align:middle line:84% And here, it's staring us in the phase. 00:12:57.980 --> 00:13:06.020 align:middle line:84% Because notice that xi, j only depends 00:13:06.020 --> 00:13:11.570 align:middle line:84% on x question mark, comma, j minus 1. 00:13:11.570 --> 00:13:14.450 align:middle line:90% [LAUGHING] Right? 00:13:14.450 --> 00:13:17.510 align:middle line:84% So of course, on your problem set, 00:13:17.510 --> 00:13:19.323 align:middle line:84% you should write things more carefully. 00:13:19.323 --> 00:13:20.990 align:middle line:84% But the basic point here is that there's 00:13:20.990 --> 00:13:23.420 align:middle line:84% a clear topological order, just by looking 00:13:23.420 --> 00:13:24.440 align:middle line:90% at that second index. 00:13:24.440 --> 00:13:27.290 align:middle line:84% Because if you think of all your x's as variables in a graph, 00:13:27.290 --> 00:13:29.640 align:middle line:84% which we've actually drawn in lecture-- 00:13:29.640 --> 00:13:33.930 align:middle line:84% so maybe these are all the i's and then the j-- 00:13:33.930 --> 00:13:37.940 align:middle line:84% so i goes down, and j goes to the right. 00:13:37.940 --> 00:13:39.440 align:middle line:84% Then essentially, this argument is 00:13:39.440 --> 00:13:43.280 align:middle line:84% saying that all the arrows point left in this graph. 00:13:43.280 --> 00:13:46.395 align:middle line:90% 00:13:46.395 --> 00:13:48.960 align:middle line:84% I suppose the way I've drawn my arrows isn't quite accurate. 00:13:48.960 --> 00:13:49.990 align:middle line:90% But it actually doesn't matter. 00:13:49.990 --> 00:13:51.573 align:middle line:84% The only thing that matters is that it 00:13:51.573 --> 00:13:53.790 align:middle line:90% goes from right to left. 00:13:53.790 --> 00:13:56.640 align:middle line:84% But I'm going to erase this, so you don't remember it. 00:13:56.640 --> 00:13:58.830 align:middle line:90% OK. 00:13:58.830 --> 00:14:00.553 align:middle line:84% So in general, just when you want 00:14:00.553 --> 00:14:02.220 align:middle line:84% to make your topological order argument, 00:14:02.220 --> 00:14:04.230 align:middle line:84% I think the totally sensible one is 00:14:04.230 --> 00:14:06.180 align:middle line:84% looking at the indices of recursion 00:14:06.180 --> 00:14:09.710 align:middle line:84% and then just trying to find some number that decreases. 00:14:09.710 --> 00:14:12.128 align:middle line:84% Incidentally, if you take a differential equation course, 00:14:12.128 --> 00:14:14.420 align:middle line:84% that's roughly how you prove that a lot of those things 00:14:14.420 --> 00:14:15.930 align:middle line:90% converge, too. 00:14:15.930 --> 00:14:19.136 align:middle line:84% So there's a generic math check that we use a lot. 00:14:19.136 --> 00:14:21.950 align:middle line:84% What do you call that in ODE where have 00:14:21.950 --> 00:14:23.442 align:middle line:90% some number that decreases? 00:14:23.442 --> 00:14:25.400 align:middle line:84% AUDIENCE: I would call that potential function. 00:14:25.400 --> 00:14:26.300 align:middle line:84% JUSTIN SOLOMON: Potential function-- 00:14:26.300 --> 00:14:28.085 align:middle line:90% that's a perfectly sensible one. 00:14:28.085 --> 00:14:29.180 align:middle line:90% It's not Lipschitz. 00:14:29.180 --> 00:14:30.830 align:middle line:90% It's some other mathematician. 00:14:30.830 --> 00:14:34.690 align:middle line:84% Anyway, OK, so let's continue SRTBOT. 00:14:34.690 --> 00:14:38.970 align:middle line:84% So next we need B, which is our Base case. 00:14:38.970 --> 00:14:41.250 align:middle line:84% So in this case, it's pretty straightforward. 00:14:41.250 --> 00:14:45.150 align:middle line:84% If I don't have any coins, I can't make any money. 00:14:45.150 --> 00:14:47.730 align:middle line:84% I have a t-shirt that says that at home. 00:14:47.730 --> 00:14:49.920 align:middle line:84% And moreover, if I can't sell anything, 00:14:49.920 --> 00:14:51.520 align:middle line:90% I can't make any money. 00:14:51.520 --> 00:14:53.460 align:middle line:84% So those are pretty straightforward cases. 00:14:53.460 --> 00:14:59.100 align:middle line:84% So we have that 0 equals x of 0, comma j. 00:14:59.100 --> 00:15:02.820 align:middle line:84% Remember, the first index is the number of coins you have. 00:15:02.820 --> 00:15:05.870 align:middle line:84% So this is saying, I can't make anything. 00:15:05.870 --> 00:15:07.110 align:middle line:90% I don't have any coins. 00:15:07.110 --> 00:15:14.080 align:middle line:84% And similarly, equals x i, comma 0 for all i, j. 00:15:14.080 --> 00:15:18.630 align:middle line:84% So this is the coins and the objects. 00:15:18.630 --> 00:15:20.070 align:middle line:90% OK. 00:15:20.070 --> 00:15:20.850 align:middle line:90% So let's see. 00:15:20.850 --> 00:15:22.800 align:middle line:84% I keep writing these problem sessions too big 00:15:22.800 --> 00:15:24.342 align:middle line:84% and then spending half of it erasing. 00:15:24.342 --> 00:15:26.440 align:middle line:84% So let's try and fit this on one board here. 00:15:26.440 --> 00:15:27.840 align:middle line:90% So we're going to do SRTBOT. 00:15:27.840 --> 00:15:32.040 align:middle line:84% Then the second-- no, the first O, 00:15:32.040 --> 00:15:34.710 align:middle line:90% because there's no O in SRT-- 00:15:34.710 --> 00:15:38.080 align:middle line:84% is the original problem that you want to solve. 00:15:38.080 --> 00:15:43.420 align:middle line:84% So of course, you start out with n objects and n coins. 00:15:43.420 --> 00:15:47.280 align:middle line:84% So the original problem we want to solve 00:15:47.280 --> 00:15:50.070 align:middle line:84% is equivalent to computing x income n. 00:15:50.070 --> 00:15:53.190 align:middle line:84% And then finally, we've got to do our runtime. 00:15:53.190 --> 00:15:57.570 align:middle line:84% T stands for runtime, or Time, I suppose. 00:15:57.570 --> 00:16:00.040 align:middle line:84% So first of all, how many problems are there? 00:16:00.040 --> 00:16:01.980 align:middle line:90% Well, there's x i, j. 00:16:01.980 --> 00:16:05.040 align:middle line:90% Both I can go from 0 to n. 00:16:05.040 --> 00:16:07.380 align:middle line:84% This is a great way to be off by 1. 00:16:07.380 --> 00:16:15.710 align:middle line:84% So there's n plus 1 squared sub problems. 00:16:15.710 --> 00:16:17.720 align:middle line:84% And how much work does each sub-problem do? 00:16:17.720 --> 00:16:19.470 align:middle line:90% Well, it does boring work. 00:16:19.470 --> 00:16:20.660 align:middle line:90% It's just a formula. 00:16:20.660 --> 00:16:21.230 align:middle line:90% Right? 00:16:21.230 --> 00:16:28.080 align:middle line:84% So there's order 1 work per sub-problem. 00:16:28.080 --> 00:16:33.750 align:middle line:84% So the overall algorithm takes n squared time. 00:16:33.750 --> 00:16:37.130 align:middle line:84% So I promised to do something in our last problem session. 00:16:37.130 --> 00:16:38.670 align:middle line:90% Then I didn't actually do it. 00:16:38.670 --> 00:16:42.380 align:middle line:84% So I did think I would spend just a minute here translating 00:16:42.380 --> 00:16:45.722 align:middle line:84% what this SRTBOT thing would mean in terms of code. 00:16:45.722 --> 00:16:47.930 align:middle line:84% Because I think that it's a little bit implicit here. 00:16:47.930 --> 00:16:50.840 align:middle line:84% In particular, I think this step here, 00:16:50.840 --> 00:16:53.203 align:middle line:84% I mean, you will see that it really clearly 00:16:53.203 --> 00:16:54.620 align:middle line:84% is going to give you an algorithm. 00:16:54.620 --> 00:16:58.690 align:middle line:84% But I think it's kind of easy to, again, just to forget what 00:16:58.690 --> 00:16:59.940 align:middle line:90% your code actually looks like. 00:16:59.940 --> 00:17:00.980 align:middle line:84% And actually, the coding problems 00:17:00.980 --> 00:17:03.410 align:middle line:84% on these problem sessions are almost too interesting 00:17:03.410 --> 00:17:05.630 align:middle line:90% and can obscure it a little bit. 00:17:05.630 --> 00:17:07.490 align:middle line:84% So I thought we'd do a boring problem 00:17:07.490 --> 00:17:10.490 align:middle line:84% and show you that it's really not so hard to do this. 00:17:10.490 --> 00:17:13.910 align:middle line:84% And in fact, we covered two different strategies in class 00:17:13.910 --> 00:17:15.920 align:middle line:84% for how to take SRTBOT and convert it 00:17:15.920 --> 00:17:17.000 align:middle line:90% into a piece of code. 00:17:17.000 --> 00:17:21.890 align:middle line:84% Although, they might have zipped past you in this 2x speed thing 00:17:21.890 --> 00:17:24.500 align:middle line:90% that you can do now. 00:17:24.500 --> 00:17:26.250 align:middle line:90% So here are two options. 00:17:26.250 --> 00:17:28.339 align:middle line:84% One of them is called memoization. 00:17:28.339 --> 00:17:30.560 align:middle line:84% And the other, I don't know, bottom up, I guess, 00:17:30.560 --> 00:17:32.132 align:middle line:84% is a reasonable phrase to describe. 00:17:32.132 --> 00:17:33.590 align:middle line:84% And so I thought we'd do them both, 00:17:33.590 --> 00:17:36.440 align:middle line:84% because they're both easy for this particular problem. 00:17:36.440 --> 00:17:39.440 align:middle line:90% 00:17:39.440 --> 00:17:41.090 align:middle line:90% OK. 00:17:41.090 --> 00:17:41.660 align:middle line:90% Right. 00:17:41.660 --> 00:17:43.890 align:middle line:90% So let's do that. 00:17:43.890 --> 00:17:47.990 align:middle line:84% So is this necessary on your homework? 00:17:47.990 --> 00:17:49.280 align:middle line:90% Strictly speaking, no. 00:17:49.280 --> 00:17:52.700 align:middle line:84% If you've gone through SRTBOT, then essentially, everything 00:17:52.700 --> 00:17:54.800 align:middle line:84% that happens after that is boilerplate, 00:17:54.800 --> 00:17:58.130 align:middle line:84% in terms of converting these steps into a piece of code 00:17:58.130 --> 00:17:58.850 align:middle line:90% or an algorithm. 00:17:58.850 --> 00:18:00.590 align:middle line:84% But I do think, just for understanding 00:18:00.590 --> 00:18:02.450 align:middle line:84% why SRTBOT makes sense, it's worth 00:18:02.450 --> 00:18:04.350 align:middle line:90% thinking about for a minute. 00:18:04.350 --> 00:18:07.700 align:middle line:90% So option A here is memoization. 00:18:07.700 --> 00:18:11.410 align:middle line:90% 00:18:11.410 --> 00:18:13.900 align:middle line:84% Ironically, I've taught and TA'd algorithms a few times, 00:18:13.900 --> 00:18:16.880 align:middle line:84% and I never actually knew what memoization meant. 00:18:16.880 --> 00:18:20.110 align:middle line:84% So I learned something from Eric's lecture the other day. 00:18:20.110 --> 00:18:24.070 align:middle line:84% Which remember, memoization is the key thing in what, 00:18:24.070 --> 00:18:27.190 align:middle line:84% apparently, is a made-up word, is memo-- 00:18:27.190 --> 00:18:30.130 align:middle line:84% if you're back in the day, and you had a steno pad, 00:18:30.130 --> 00:18:31.720 align:middle line:90% and you were writing down stuff. 00:18:31.720 --> 00:18:35.830 align:middle line:84% Because that's how you solved problems, with your slide rule. 00:18:35.830 --> 00:18:40.627 align:middle line:84% Then essentially, the idea is that, if I compute x i, 00:18:40.627 --> 00:18:43.100 align:middle line:84% j for some i, j pair, I shouldn't compute it again. 00:18:43.100 --> 00:18:46.190 align:middle line:84% I should just write it down on my memo pad. 00:18:46.190 --> 00:18:48.020 align:middle line:84% Stenoization sounds better to me. 00:18:48.020 --> 00:18:52.580 align:middle line:84% But I suppose we'd have to go back to the 1940s and fix it. 00:18:52.580 --> 00:18:55.070 align:middle line:84% OK, so let's actually write down. 00:18:55.070 --> 00:18:57.320 align:middle line:84% I'm going to write down pseudocode, that will probably 00:18:57.320 --> 00:19:00.120 align:middle line:84% look more like Matlab, because I'm that kind of guy. 00:19:00.120 --> 00:19:01.790 align:middle line:84% So let's say that I wanted to make 00:19:01.790 --> 00:19:11.490 align:middle line:84% a function, which, I guess, is revenue of i, j, like that. 00:19:11.490 --> 00:19:14.000 align:middle line:90% Bah. 00:19:14.000 --> 00:19:16.632 align:middle line:84% And this is the thing I wanted to compute. 00:19:16.632 --> 00:19:18.965 align:middle line:84% That's actually going to be a problem, because we're not 00:19:18.965 --> 00:19:21.550 align:middle line:90% going to be able to see. 00:19:21.550 --> 00:19:23.350 align:middle line:90% OK, right. 00:19:23.350 --> 00:19:28.510 align:middle line:84% So in addition to this, I'm going to pass in an array 00:19:28.510 --> 00:19:31.855 align:middle line:84% x, which is going to be like my memo pad. 00:19:31.855 --> 00:19:33.730 align:middle line:84% This is going to be terrible coding practice, 00:19:33.730 --> 00:19:36.340 align:middle line:90% but easy board coding practice. 00:19:36.340 --> 00:19:38.650 align:middle line:84% So if I were in C++, maybe I'm passing by reference, 00:19:38.650 --> 00:19:40.560 align:middle line:90% so that when I edit-- 00:19:40.560 --> 00:19:44.320 align:middle line:84% that's a treble clef, but whatever-- 00:19:44.320 --> 00:19:47.310 align:middle line:84% when I edit x, it actually persists when I recurse. 00:19:47.310 --> 00:19:48.760 align:middle line:84% This is terrible coding practice, 00:19:48.760 --> 00:19:50.000 align:middle line:90% and you shouldn't do it. 00:19:50.000 --> 00:19:50.752 align:middle line:90% OK? 00:19:50.752 --> 00:19:52.210 align:middle line:84% But it's just going to be because I 00:19:52.210 --> 00:19:55.480 align:middle line:84% don't want to write too many lines on the board here. 00:19:55.480 --> 00:19:58.000 align:middle line:90% And maybe we initialize. 00:19:58.000 --> 00:20:03.630 align:middle line:84% We have some helper function to-- 00:20:03.630 --> 00:20:06.300 align:middle line:84% let's see, we want our revenue to be big. 00:20:06.300 --> 00:20:08.120 align:middle line:90% Well, actually no. 00:20:08.120 --> 00:20:09.910 align:middle line:84% We'll just initialize it to not a number, 00:20:09.910 --> 00:20:11.910 align:middle line:84% so that we know that we haven't computed it yet. 00:20:11.910 --> 00:20:13.740 align:middle line:90% How about that? 00:20:13.740 --> 00:20:17.807 align:middle line:90% OK, so what should we do? 00:20:17.807 --> 00:20:20.390 align:middle line:84% Well, if we're going to memoize, the first thing we should do, 00:20:20.390 --> 00:20:22.977 align:middle line:84% any time that I call my revenue function on an i, 00:20:22.977 --> 00:20:24.950 align:middle line:84% j pair is check that I've already computed it. 00:20:24.950 --> 00:20:25.940 align:middle line:90% Yeah? 00:20:25.940 --> 00:20:29.668 align:middle line:84% So in my goofy, bad board-coding style here, what could I do? 00:20:29.668 --> 00:20:31.460 align:middle line:84% I'd say, well, if I've already computed it, 00:20:31.460 --> 00:20:33.320 align:middle line:84% then this thing won't equal NaN anymore 00:20:33.320 --> 00:20:34.740 align:middle line:90% and won't be not a number. 00:20:34.740 --> 00:20:42.060 align:middle line:84% So I can say, OK, if x is not equal to not a number-- 00:20:42.060 --> 00:20:45.000 align:middle line:84% so in other words, it is a number-- 00:20:45.000 --> 00:20:45.500 align:middle line:90% return. 00:20:45.500 --> 00:20:49.210 align:middle line:90% 00:20:49.210 --> 00:20:52.330 align:middle line:84% And this, I think that this little line of code here, 00:20:52.330 --> 00:20:53.390 align:middle line:90% it gets a little lost. 00:20:53.390 --> 00:20:57.020 align:middle line:84% But this, we should put sparkles around it. 00:20:57.020 --> 00:20:59.590 align:middle line:84% This is the magic of dynamic programming, 00:20:59.590 --> 00:21:03.310 align:middle line:84% because I just killed recursive calls. 00:21:03.310 --> 00:21:07.390 align:middle line:84% Even if i and j are 17 and 23, if I already computed it, 00:21:07.390 --> 00:21:08.290 align:middle line:90% I'm done, right? 00:21:08.290 --> 00:21:10.990 align:middle line:84% I don't have to call my recursion again. 00:21:10.990 --> 00:21:11.950 align:middle line:90% OK. 00:21:11.950 --> 00:21:13.960 align:middle line:84% And otherwise, what am I going to do? 00:21:13.960 --> 00:21:17.330 align:middle line:90% 00:21:17.330 --> 00:21:21.008 align:middle line:84% Well, otherwise, I'll maybe call-- 00:21:21.008 --> 00:21:22.300 align:middle line:90% do I want to write it all down? 00:21:22.300 --> 00:21:23.717 align:middle line:84% I don't want to write it all down. 00:21:23.717 --> 00:21:27.030 align:middle line:90% 00:21:27.030 --> 00:21:35.000 align:middle line:84% So otherwise, I'm going to evaluate, R, where 00:21:35.000 --> 00:21:36.890 align:middle line:90% R is this formula over here. 00:21:36.890 --> 00:21:43.970 align:middle line:84% Notice that this will require recursive calls, right? 00:21:43.970 --> 00:21:53.131 align:middle line:84% And I'm going to store it in x i, j and then return x i, j. 00:21:53.131 --> 00:21:57.110 align:middle line:90% 00:21:57.110 --> 00:21:57.620 align:middle line:90% OK? 00:21:57.620 --> 00:21:59.090 align:middle line:84% So basically, the only difference 00:21:59.090 --> 00:22:01.940 align:middle line:84% between what we've seen in the first 2/3 of 6006 00:22:01.940 --> 00:22:05.930 align:middle line:84% and now is this beautiful line of code, saying, if I already 00:22:05.930 --> 00:22:07.820 align:middle line:90% computed this thing, return it. 00:22:07.820 --> 00:22:11.400 align:middle line:84% And this is the memoized version of our algorithm. 00:22:11.400 --> 00:22:15.380 align:middle line:84% I think this is the easiest one to maybe think about. 00:22:15.380 --> 00:22:16.970 align:middle line:84% But actually, from a runtime analysis, 00:22:16.970 --> 00:22:19.098 align:middle line:90% it's a little bit annoying. 00:22:19.098 --> 00:22:21.140 align:middle line:84% It's not in the sense that we convinced ourselves 00:22:21.140 --> 00:22:22.160 align:middle line:90% that SRTBOT is OK. 00:22:22.160 --> 00:22:24.410 align:middle line:84% But of course, if you're thinking about your recursion 00:22:24.410 --> 00:22:26.990 align:middle line:84% tree, what's happening is that you're maybe 00:22:26.990 --> 00:22:30.140 align:middle line:84% convincing yourself that this piece can be lopped off 00:22:30.140 --> 00:22:31.920 align:middle line:90% in your function calls. 00:22:31.920 --> 00:22:35.850 align:middle line:84% So you have to do your counting carefully. 00:22:35.850 --> 00:22:38.780 align:middle line:84% There's a different way to implement the same thing. 00:22:38.780 --> 00:22:42.198 align:middle line:84% So this would be option B. This is maybe 00:22:42.198 --> 00:22:43.740 align:middle line:84% more efficient, maybe less efficient, 00:22:43.740 --> 00:22:44.823 align:middle line:90% depending on your problem. 00:22:44.823 --> 00:22:47.157 align:middle line:84% But these are all within constant factors of each other, 00:22:47.157 --> 00:22:48.130 align:middle line:90% for the most part-- 00:22:48.130 --> 00:22:49.920 align:middle line:84% not always, but for the most part. 00:22:49.920 --> 00:22:53.400 align:middle line:90% This would be bottom up. 00:22:53.400 --> 00:22:55.650 align:middle line:84% And this is the idea of, rather than just 00:22:55.650 --> 00:22:58.320 align:middle line:84% taking our recursive algorithm that we already know, 00:22:58.320 --> 00:23:01.033 align:middle line:84% and then just checking a table to say, like, OK, 00:23:01.033 --> 00:23:01.950 align:middle line:90% did I already do this? 00:23:01.950 --> 00:23:05.040 align:middle line:84% And in that case, return it, in the bottom-up version, 00:23:05.040 --> 00:23:09.000 align:middle line:84% I'm going to build up my array x i, j because so there's 00:23:09.000 --> 00:23:12.272 align:middle line:90% no recursion at all. 00:23:12.272 --> 00:23:13.480 align:middle line:90% So what would that look like? 00:23:13.480 --> 00:23:16.770 align:middle line:84% So in the bottom-up case, notice that, in some sense, 00:23:16.770 --> 00:23:18.570 align:middle line:84% memoization is a top-down strategy. 00:23:18.570 --> 00:23:20.940 align:middle line:90% I would call it on n, comma n. 00:23:20.940 --> 00:23:22.345 align:middle line:84% Here, we're going to start from 0 00:23:22.345 --> 00:23:23.720 align:middle line:84% and work our way toward n, right? 00:23:23.720 --> 00:23:29.910 align:middle line:84% So we'll start with x 0, j equals 00:23:29.910 --> 00:23:34.590 align:middle line:90% x i, 0 equals 0 for all i, j. 00:23:34.590 --> 00:23:37.710 align:middle line:84% Obviously, I can do this with a for loop. 00:23:37.710 --> 00:23:41.010 align:middle line:84% And now, well, remember, if we think 00:23:41.010 --> 00:23:42.720 align:middle line:84% about our topological order, x i, 00:23:42.720 --> 00:23:45.895 align:middle line:84% j only depends on previous j's, right? 00:23:45.895 --> 00:23:48.270 align:middle line:84% So it makes sense to have an outer loop, which is over j. 00:23:48.270 --> 00:23:54.600 align:middle line:90% 00:23:54.600 --> 00:23:58.350 align:middle line:84% And now, inside of this outer loop, 00:23:58.350 --> 00:24:02.460 align:middle line:84% I can compute anything that I want in that j column of x. 00:24:02.460 --> 00:24:05.220 align:middle line:84% And I'm in good shape, because I'm building it up one column 00:24:05.220 --> 00:24:06.400 align:middle line:90% at a time, right? 00:24:06.400 --> 00:24:13.480 align:middle line:84% So in particular, now we can do our loop over i 00:24:13.480 --> 00:24:19.900 align:middle line:84% and then just have x j and now evaluate our R step 00:24:19.900 --> 00:24:22.000 align:middle line:90% in our SRTBOT paradigm. 00:24:22.000 --> 00:24:23.680 align:middle line:84% And notice that that's perfectly fine. 00:24:23.680 --> 00:24:26.425 align:middle line:84% Because by the time I get to computing x i, 00:24:26.425 --> 00:24:29.650 align:middle line:84% j, I've already filled in x i, j minus 1, 00:24:29.650 --> 00:24:32.600 align:middle line:84% which is all I needed to evaluate that formula. 00:24:32.600 --> 00:24:34.740 align:middle line:84% So what are the advantages and disadvantages here? 00:24:34.740 --> 00:24:37.760 align:middle line:84% So notice that here, our runtime is staring you in the phase. 00:24:37.760 --> 00:24:38.260 align:middle line:90% Right? 00:24:38.260 --> 00:24:43.620 align:middle line:84% We have n squared sub-problems, order 1 work, and you're done. 00:24:43.620 --> 00:24:46.820 align:middle line:84% On the other hand, there's some possibility. 00:24:46.820 --> 00:24:49.850 align:middle line:84% If you were an old-school AI person, 00:24:49.850 --> 00:24:55.450 align:middle line:84% you might be able to do some pruning on your left-hand side 00:24:55.450 --> 00:24:56.533 align:middle line:90% that I can't do over here. 00:24:56.533 --> 00:24:57.033 align:middle line:90% Right? 00:24:57.033 --> 00:24:58.480 align:middle line:84% So here, I'm literally evaluating 00:24:58.480 --> 00:25:01.633 align:middle line:90% every entry of x i, j. 00:25:01.633 --> 00:25:03.550 align:middle line:84% It's not the case for this particular problem, 00:25:03.550 --> 00:25:07.913 align:middle line:84% but maybe x i, j only depends on x i, j minus 5. 00:25:07.913 --> 00:25:10.330 align:middle line:84% This strategy is going to still build up that whole table. 00:25:10.330 --> 00:25:12.440 align:middle line:84% This one, maybe you can skip over some entries. 00:25:12.440 --> 00:25:14.090 align:middle line:90% So in practice, it could help. 00:25:14.090 --> 00:25:17.428 align:middle line:84% On the other hand, here, I've got a bunch of recursive calls 00:25:17.428 --> 00:25:18.970 align:middle line:84% I've put on the stack of my computer, 00:25:18.970 --> 00:25:20.532 align:middle line:90% that here, I don't have. 00:25:20.532 --> 00:25:22.990 align:middle line:84% So I think, actually, because of the overhead of recursion, 00:25:22.990 --> 00:25:24.880 align:middle line:84% typically, the strategy on the right 00:25:24.880 --> 00:25:26.980 align:middle line:90% is preferred; also, for clarity. 00:25:26.980 --> 00:25:30.190 align:middle line:84% But that's a blanket statement that I shouldn't make. 00:25:30.190 --> 00:25:34.290 align:middle line:84% OK, so anyway, I think I've done this problem to death. 00:25:34.290 --> 00:25:36.378 align:middle line:90% Are there any questions here? 00:25:36.378 --> 00:25:38.920 align:middle line:84% I just thought I'd fill in for something I promised last time 00:25:38.920 --> 00:25:41.080 align:middle line:90% and didn't actually do. 00:25:41.080 --> 00:25:43.090 align:middle line:90% OK, fabulous. 00:25:43.090 --> 00:25:47.710 align:middle line:90% So we'll go on to problem 9-2. 00:25:47.710 --> 00:25:49.540 align:middle line:84% So this is continuing from last time 00:25:49.540 --> 00:25:52.660 align:middle line:84% in the saga of Tim the Beaver here. 00:25:52.660 --> 00:25:55.300 align:middle line:84% So I forget what Tim the Beaver was doing in our last problem 00:25:55.300 --> 00:25:55.800 align:middle line:90% session. 00:25:55.800 --> 00:26:01.060 align:middle line:84% But today, Tim the Beaver is going to the career fair. 00:26:01.060 --> 00:26:04.390 align:middle line:84% And as we all know, the only real purpose 00:26:04.390 --> 00:26:09.420 align:middle line:84% of going to a career fair is to pick up free stuff. 00:26:09.420 --> 00:26:12.000 align:middle line:90% 00:26:12.000 --> 00:26:12.630 align:middle line:90% We joke. 00:26:12.630 --> 00:26:14.160 align:middle line:84% Actually, you guys should all go to the career fair. 00:26:14.160 --> 00:26:15.990 align:middle line:84% I got my first job out of college 00:26:15.990 --> 00:26:19.470 align:middle line:84% by going to a career fair and haranguing 00:26:19.470 --> 00:26:22.270 align:middle line:84% somebody that picks our booth, until they let me in. 00:26:22.270 --> 00:26:27.330 align:middle line:84% But in any event, so Tim the Beaver 00:26:27.330 --> 00:26:28.890 align:middle line:84% is not interested in getting a job, 00:26:28.890 --> 00:26:32.220 align:middle line:84% but rather just wants swag, just wants free stuff out 00:26:32.220 --> 00:26:34.040 align:middle line:90% of booths at the career fair. 00:26:34.040 --> 00:26:35.430 align:middle line:90% OK? 00:26:35.430 --> 00:26:39.700 align:middle line:84% So in this particular problem, there's n booths-- 00:26:39.700 --> 00:26:40.890 align:middle line:90% is it booths? 00:26:40.890 --> 00:26:43.470 align:middle line:90% It's certainly not boots. 00:26:43.470 --> 00:26:44.340 align:middle line:90% I don't know. 00:26:44.340 --> 00:26:47.640 align:middle line:84% There are n booths, each of which has a swag. 00:26:47.640 --> 00:26:52.350 align:middle line:84% And in particular, each swag has a value 00:26:52.350 --> 00:26:54.660 align:middle line:84% associated to it, which is Ci, which 00:26:54.660 --> 00:27:00.780 align:middle line:90% is the coolness of object i. 00:27:00.780 --> 00:27:03.420 align:middle line:90% It additionally has Wi. 00:27:03.420 --> 00:27:07.930 align:middle line:90% This is the weight of object i. 00:27:07.930 --> 00:27:12.690 align:middle line:84% And just to make this problem verbally difficult 00:27:12.690 --> 00:27:16.860 align:middle line:84% to communicate, there's a W-A-I-T associated with each 00:27:16.860 --> 00:27:21.930 align:middle line:84% object, which is the time it takes to wait in line and pick 00:27:21.930 --> 00:27:22.910 align:middle line:90% up object i. 00:27:22.910 --> 00:27:23.410 align:middle line:90% OK? 00:27:23.410 --> 00:27:26.460 align:middle line:84% And Tim the Beaver, if there's some ridiculously cool object 00:27:26.460 --> 00:27:29.970 align:middle line:84% with a little wait time, he might just keep getting in line 00:27:29.970 --> 00:27:31.760 align:middle line:90% and getting more of that object. 00:27:31.760 --> 00:27:37.360 align:middle line:84% So unlike Ceal Naffrey on our first problem, 00:27:37.360 --> 00:27:39.970 align:middle line:84% Tim the Beaver is perfectly happy to have more than one 00:27:39.970 --> 00:27:41.150 align:middle line:90% of the same thing. 00:27:41.150 --> 00:27:41.650 align:middle line:90% OK. 00:27:41.650 --> 00:27:45.080 align:middle line:90% 00:27:45.080 --> 00:27:47.660 align:middle line:84% In addition to this, just to make 00:27:47.660 --> 00:27:49.910 align:middle line:84% this problem, in my opinion, slightly more 00:27:49.910 --> 00:27:53.780 align:middle line:84% annoying and point-losing, Tim the Beaver 00:27:53.780 --> 00:27:57.108 align:middle line:84% also takes one minute to get in line at any booth. 00:27:57.108 --> 00:27:59.150 align:middle line:84% So we're just going to have to remember that when 00:27:59.150 --> 00:28:01.610 align:middle line:90% we account for our time ti. 00:28:01.610 --> 00:28:03.620 align:middle line:90% OK. 00:28:03.620 --> 00:28:08.250 align:middle line:84% So let's continue adding some more constants to our problem. 00:28:08.250 --> 00:28:11.750 align:middle line:84% So each booth has an object which has coolness, Ci, 00:28:11.750 --> 00:28:14.690 align:middle line:90% weight Wi, time ti. 00:28:14.690 --> 00:28:17.000 align:middle line:90% Tim is carrying a bag. 00:28:17.000 --> 00:28:25.340 align:middle line:84% The bag can hold a particular weight. b. 00:28:25.340 --> 00:28:32.120 align:middle line:84% So this is the max weight that Tim can hold in his bag 00:28:32.120 --> 00:28:34.490 align:middle line:90% at any given time. 00:28:34.490 --> 00:28:38.870 align:middle line:84% And finally, Tim is a greedy beaver, 00:28:38.870 --> 00:28:44.140 align:middle line:84% but he also can go home, or go back to his dam, 00:28:44.140 --> 00:28:48.450 align:middle line:90% I suppose, and empty his bag. 00:28:48.450 --> 00:28:48.950 align:middle line:90% Right? 00:28:48.950 --> 00:29:00.760 align:middle line:84% And so h is the amount of time to go home and back 00:29:00.760 --> 00:29:03.790 align:middle line:84% and empty his bag, in the meantime. 00:29:03.790 --> 00:29:06.280 align:middle line:84% And again, just to be annoying, don't 00:29:06.280 --> 00:29:09.027 align:middle line:84% forget he incurs plus 1 to get in the next line. 00:29:09.027 --> 00:29:11.110 align:middle line:84% This is what made my answer wrong, and I'm bitter. 00:29:11.110 --> 00:29:12.910 align:middle line:84% So I'm going to keep complaining about it. 00:29:12.910 --> 00:29:14.410 align:middle line:90% OK. 00:29:14.410 --> 00:29:17.240 align:middle line:84% So of course, what he wants is the max. 00:29:17.240 --> 00:29:20.110 align:middle line:90% 00:29:20.110 --> 00:29:22.070 align:middle line:90% What would economists call this? 00:29:22.070 --> 00:29:22.900 align:middle line:90% I don't know. 00:29:22.900 --> 00:29:29.955 align:middle line:84% But for Tim the Beaver, he wants the max total coolness, or MTC, 00:29:29.955 --> 00:29:32.080 align:middle line:84% which is, of course, a number that we're all trying 00:29:32.080 --> 00:29:37.600 align:middle line:90% to optimize, in k minutes. 00:29:37.600 --> 00:29:39.880 align:middle line:84% You might remember those old TV shows, 00:29:39.880 --> 00:29:42.070 align:middle line:84% where you get one minute in a grocery store 00:29:42.070 --> 00:29:46.340 align:middle line:84% to empty the shells into your cart kind of thing. 00:29:46.340 --> 00:29:51.340 align:middle line:84% So he wants to do this, and the computation time 00:29:51.340 --> 00:29:54.930 align:middle line:84% that he's reserved for this is an order nbk. 00:29:54.930 --> 00:29:56.330 align:middle line:90% And I know it's a big setup. 00:29:56.330 --> 00:29:59.060 align:middle line:84% I tried to document all the different constants that 00:29:59.060 --> 00:30:00.410 align:middle line:90% are in this problem. 00:30:00.410 --> 00:30:02.210 align:middle line:90% I don't think I missed any here. 00:30:02.210 --> 00:30:03.980 align:middle line:90% OK, fabulous. 00:30:03.980 --> 00:30:06.500 align:middle line:90% So incidentally, continuing on-- 00:30:06.500 --> 00:30:07.490 align:middle line:90% AUDIENCE: What's k? 00:30:07.490 --> 00:30:10.670 align:middle line:84% JUSTIN SOLOMON: k-- k is the total amount of time 00:30:10.670 --> 00:30:18.490 align:middle line:84% that Tim the Beaver has allotted to do his job fair scavenging. 00:30:18.490 --> 00:30:20.682 align:middle line:90% Fabulous. 00:30:20.682 --> 00:30:22.830 align:middle line:90% Any other? 00:30:22.830 --> 00:30:24.180 align:middle line:90% Cool. 00:30:24.180 --> 00:30:26.340 align:middle line:90% OK. 00:30:26.340 --> 00:30:29.190 align:middle line:84% Notice that this is going to be an example of a problem that 00:30:29.190 --> 00:30:31.380 align:middle line:84% was not kosher in last week's problem session, 00:30:31.380 --> 00:30:34.390 align:middle line:84% in the sense that k is included in our runtime. 00:30:34.390 --> 00:30:34.890 align:middle line:90% Right? 00:30:34.890 --> 00:30:35.850 align:middle line:90% But what is k? 00:30:35.850 --> 00:30:37.660 align:middle line:90% It's just a number. 00:30:37.660 --> 00:30:41.950 align:middle line:84% k doesn't scale in the size of your problem in a linear way. 00:30:41.950 --> 00:30:44.550 align:middle line:84% So it's not going to matter for how we solve our problem 00:30:44.550 --> 00:30:48.090 align:middle line:84% But it is just a feature that's worth pointing out. 00:30:48.090 --> 00:30:48.720 align:middle line:90% OK. 00:30:48.720 --> 00:30:51.600 align:middle line:84% So how do we solve dynamic programming problems? 00:30:51.600 --> 00:30:58.110 align:middle line:84% We use SRTBOT, or a Señor BST, if you are watching previous 00:30:58.110 --> 00:30:59.880 align:middle line:90% iterations of this course. 00:30:59.880 --> 00:31:04.650 align:middle line:90% OK, so right, so let's do that. 00:31:04.650 --> 00:31:06.520 align:middle line:84% See, I'm trying to conserve space. 00:31:06.520 --> 00:31:09.610 align:middle line:84% This is not going to end up succeeding. 00:31:09.610 --> 00:31:13.230 align:middle line:84% So again, what are the different sub-problems here? 00:31:13.230 --> 00:31:15.930 align:middle line:84% Well, what are the different things that 00:31:15.930 --> 00:31:18.550 align:middle line:90% are limiting Tim the Beaver? 00:31:18.550 --> 00:31:20.280 align:middle line:90% What are his constraints? 00:31:20.280 --> 00:31:22.870 align:middle line:90% Well, he only has so much time. 00:31:22.870 --> 00:31:27.180 align:middle line:84% And this is going to sound more philosophical in intent, 00:31:27.180 --> 00:31:29.840 align:middle line:84% but time always moves forward for Tim the Beaver. 00:31:29.840 --> 00:31:32.580 align:middle line:84% So this is a pretty good candidate 00:31:32.580 --> 00:31:34.435 align:middle line:90% in terms of dynamic programming. 00:31:34.435 --> 00:31:36.810 align:middle line:84% Because there's not going to be some cyclical dependency. 00:31:36.810 --> 00:31:38.460 align:middle line:84% Remember that in dynamic programming, 00:31:38.460 --> 00:31:41.160 align:middle line:84% we're all about trying to identify topological orderings 00:31:41.160 --> 00:31:42.580 align:middle line:90% in our sub-problems. 00:31:42.580 --> 00:31:44.700 align:middle line:84% And when you see something like time, 00:31:44.700 --> 00:31:48.690 align:middle line:84% not only does it also begin with t, but it's useful in the sense 00:31:48.690 --> 00:31:50.460 align:middle line:90% that time moves forward. 00:31:50.460 --> 00:31:53.640 align:middle line:84% There's never a case where Tim the Beaver 00:31:53.640 --> 00:31:56.280 align:middle line:84% purchases a weird Warp Speed airplane 00:31:56.280 --> 00:31:58.638 align:middle line:90% and somehow goes back in time. 00:31:58.638 --> 00:32:00.930 align:middle line:84% That doesn't happen in this particular homework problem 00:32:00.930 --> 00:32:02.470 align:middle line:84% and for Tim the Beaver's for sake, 00:32:02.470 --> 00:32:04.040 align:middle line:90% I hope in no homework problems. 00:32:04.040 --> 00:32:07.057 align:middle line:90% 00:32:07.057 --> 00:32:08.640 align:middle line:84% So this is a long-winded way of saying 00:32:08.640 --> 00:32:11.190 align:middle line:84% that time is a pretty reasonable constraint 00:32:11.190 --> 00:32:14.280 align:middle line:84% to put in our problem, not a constraint as much as an index, 00:32:14.280 --> 00:32:15.840 align:middle line:90% I guess. 00:32:15.840 --> 00:32:18.210 align:middle line:84% Moreover, there's another thing which 00:32:18.210 --> 00:32:21.000 align:middle line:84% is limiting Tim the Beaver, which 00:32:21.000 --> 00:32:22.660 align:middle line:90% is the capacity of his bag. 00:32:22.660 --> 00:32:25.650 align:middle line:84% Remember, he can only hold weight b. 00:32:25.650 --> 00:32:28.830 align:middle line:84% But this one should give you the heebie-jeebies a little bit. 00:32:28.830 --> 00:32:31.920 align:middle line:84% Because this problem, as a twist, 00:32:31.920 --> 00:32:35.730 align:middle line:84% has allowed the bag to empty itself out. 00:32:35.730 --> 00:32:37.530 align:middle line:84% So it's not true that somehow, you 00:32:37.530 --> 00:32:42.690 align:middle line:84% can come up with sub-problems where Tim the Beaver is just 00:32:42.690 --> 00:32:46.250 align:middle line:84% monotonically decreasing the weight of his bag. 00:32:46.250 --> 00:32:50.290 align:middle line:84% However, if he does choose to decrease the weight of his bag, 00:32:50.290 --> 00:32:51.710 align:middle line:90% he has to spend time doing it. 00:32:51.710 --> 00:32:54.680 align:middle line:84% So time continues to move forward for Tim the Beaver. 00:32:54.680 --> 00:32:57.280 align:middle line:84% And that's what's going to give us our topological order. 00:32:57.280 --> 00:32:57.877 align:middle line:90% Yeah? 00:32:57.877 --> 00:32:59.710 align:middle line:84% This is a little too philosophical, I guess. 00:32:59.710 --> 00:33:02.710 align:middle line:84% But in some sense, this is a long-winded way of saying, 00:33:02.710 --> 00:33:07.630 align:middle line:84% for our SRTBOT paradigm here, a totally reasonable thing to do 00:33:07.630 --> 00:33:12.163 align:middle line:90% would be to have x i, j-- 00:33:12.163 --> 00:33:14.890 align:middle line:84% I don't think, in this class, we do this definition notation. 00:33:14.890 --> 00:33:24.790 align:middle line:84% So just x i, j equals the max coolness 00:33:24.790 --> 00:33:32.610 align:middle line:84% where he has i minutes, and he has j weight-- 00:33:32.610 --> 00:33:35.370 align:middle line:90% 00:33:35.370 --> 00:33:36.960 align:middle line:84% let me glance at my answer to see 00:33:36.960 --> 00:33:40.350 align:middle line:84% if it's left in his bag or weight that he's carrying. 00:33:40.350 --> 00:33:42.390 align:middle line:90% Left in his bag-- 00:33:42.390 --> 00:33:45.090 align:middle line:84% either one would make a reasonable problem. 00:33:45.090 --> 00:33:47.253 align:middle line:84% I'm just bad at looking at my notes 00:33:47.253 --> 00:33:48.920 align:middle line:84% and seeing them disagree with the board. 00:33:48.920 --> 00:33:51.330 align:middle line:84% So I'm going to try and stay consistent. 00:33:51.330 --> 00:33:56.400 align:middle line:84% OK, so x i, j is the MTC, but in i minutes with j weight left, 00:33:56.400 --> 00:34:00.890 align:middle line:84% rather than in k minutes with b weight, which is 00:34:00.890 --> 00:34:02.660 align:middle line:90% going to be our base problem. 00:34:02.660 --> 00:34:03.440 align:middle line:90% OK. 00:34:03.440 --> 00:34:05.885 align:middle line:90% Oh no, I did it out of order. 00:34:05.885 --> 00:34:06.510 align:middle line:90% Disregard that. 00:34:06.510 --> 00:34:08.100 align:middle line:90% We'll get to the b in a minute. 00:34:08.100 --> 00:34:08.600 align:middle line:90% OK. 00:34:08.600 --> 00:34:16.909 align:middle line:90% 00:34:16.909 --> 00:34:21.285 align:middle line:90% OK, so that's our sub-problems. 00:34:21.285 --> 00:34:24.929 align:middle line:90% 00:34:24.929 --> 00:34:29.196 align:middle line:90% So now let's do the R in SRTBOT. 00:34:29.196 --> 00:34:31.882 align:middle line:84% [LAUGHING] I hate this classroom so much. 00:34:31.882 --> 00:34:34.726 align:middle line:90% 00:34:34.726 --> 00:34:35.900 align:middle line:90% I'm sorry. 00:34:35.900 --> 00:34:40.659 align:middle line:84% So right, so let's say that Tim the Beaver has i minutes left 00:34:40.659 --> 00:34:41.920 align:middle line:90% on the clock. 00:34:41.920 --> 00:34:43.690 align:middle line:90% And he has j weight in his bag. 00:34:43.690 --> 00:34:46.820 align:middle line:84% He's got a number of actions that he can take. 00:34:46.820 --> 00:34:47.538 align:middle line:90% Yeah? 00:34:47.538 --> 00:34:49.580 align:middle line:84% And let's think about what all those actions are. 00:34:49.580 --> 00:34:54.409 align:middle line:84% By the way, there's one thing that plausibly, Tim the Beaver 00:34:54.409 --> 00:34:55.040 align:middle line:90% could do. 00:34:55.040 --> 00:34:58.640 align:middle line:84% But he doesn't really need to, is do nothing now, but then 00:34:58.640 --> 00:35:01.908 align:middle line:90% in 10 seconds, do something. 00:35:01.908 --> 00:35:03.700 align:middle line:84% You could account for that in this problem, 00:35:03.700 --> 00:35:05.380 align:middle line:90% but there's not a reason, right? 00:35:05.380 --> 00:35:07.120 align:middle line:84% He might as well stack up all his actions 00:35:07.120 --> 00:35:11.025 align:middle line:84% and then leave all of his leftover time at the end. 00:35:11.025 --> 00:35:12.900 align:middle line:84% You convince yourself that that's sort of OK. 00:35:12.900 --> 00:35:15.980 align:middle line:84% Tim prefers a compressed schedule. 00:35:15.980 --> 00:35:16.480 align:middle line:90% Right. 00:35:16.480 --> 00:35:18.535 align:middle line:84% So he's got a lot of energy, this Beaver. 00:35:18.535 --> 00:35:19.410 align:middle line:90% That's what they say. 00:35:19.410 --> 00:35:23.520 align:middle line:84% They're nature's construction workers, something? 00:35:23.520 --> 00:35:25.450 align:middle line:90% OK. 00:35:25.450 --> 00:35:28.570 align:middle line:84% All right, so let's think about all of our options. 00:35:28.570 --> 00:35:32.263 align:middle line:84% So for one, Tim the Beaver could not do a damn thing. 00:35:32.263 --> 00:35:34.180 align:middle line:84% He could just sit around for the rest of time, 00:35:34.180 --> 00:35:36.220 align:middle line:84% and that would be perfectly fine. 00:35:36.220 --> 00:35:39.690 align:middle line:84% So a different way of putting that is that he could give up. 00:35:39.690 --> 00:35:43.950 align:middle line:84% How much coolness would Tim get from giving up? 00:35:43.950 --> 00:35:44.610 align:middle line:90% 0. 00:35:44.610 --> 00:35:45.930 align:middle line:90% That's right, kids. 00:35:45.930 --> 00:35:49.230 align:middle line:90% Giving up makes you zero cool. 00:35:49.230 --> 00:35:53.760 align:middle line:84% So OK, so Tim the Beaver is trying to maximize. 00:35:53.760 --> 00:35:55.330 align:middle line:84% He has a lot of different options. 00:35:55.330 --> 00:36:02.850 align:middle line:84% One of them is 0, meaning he gave up. 00:36:02.850 --> 00:36:03.350 align:middle line:90% Right? 00:36:03.350 --> 00:36:04.600 align:middle line:90% Notice he could recurse. 00:36:04.600 --> 00:36:06.880 align:middle line:84% Like, x-- I guess what would be-- 00:36:06.880 --> 00:36:11.140 align:middle line:84% he could give up for one minute, and have that be x i minus 1j, 00:36:11.140 --> 00:36:12.760 align:middle line:90% or something. 00:36:12.760 --> 00:36:14.880 align:middle line:84% I forget if I'm going to do i plus 1 or i 00:36:14.880 --> 00:36:17.553 align:middle line:90% minus 1. i minus 1j. 00:36:17.553 --> 00:36:18.470 align:middle line:90% But there's no reason. 00:36:18.470 --> 00:36:20.175 align:middle line:90% He can just give up and stop. 00:36:20.175 --> 00:36:21.800 align:middle line:84% That would just be extra recursive cost 00:36:21.800 --> 00:36:23.820 align:middle line:90% for no good reason. 00:36:23.820 --> 00:36:24.320 align:middle line:90% OK. 00:36:24.320 --> 00:36:25.940 align:middle line:84% The next thing that he could do is 00:36:25.940 --> 00:36:28.160 align:middle line:84% he could get in line for a booth. 00:36:28.160 --> 00:36:29.480 align:middle line:90% Right? 00:36:29.480 --> 00:36:32.030 align:middle line:84% So first, let's work out what happens then. 00:36:32.030 --> 00:36:35.150 align:middle line:90% So for one, he gets coolness. 00:36:35.150 --> 00:36:37.160 align:middle line:84% Let's say that he gets into booth k. 00:36:37.160 --> 00:36:40.790 align:middle line:84% So he gets coolness Ck when he does that. 00:36:40.790 --> 00:36:42.848 align:middle line:90% And now he can recurse. 00:36:42.848 --> 00:36:44.640 align:middle line:84% So first, you have to account for the time. 00:36:44.640 --> 00:36:48.380 align:middle line:90% So it takes tk-- 00:36:48.380 --> 00:36:51.820 align:middle line:90% that's a t-- time. 00:36:51.820 --> 00:36:52.540 align:middle line:90% Or does it? 00:36:52.540 --> 00:36:53.050 align:middle line:90% No. 00:36:53.050 --> 00:36:54.717 align:middle line:84% Because it takes an extra minute for him 00:36:54.717 --> 00:36:56.950 align:middle line:84% to get in the next line, or to get in this line. 00:36:56.950 --> 00:37:00.100 align:middle line:90% I guess this is better. 00:37:00.100 --> 00:37:07.180 align:middle line:84% And moreover, he needs to account for j minus Wk, 00:37:07.180 --> 00:37:08.140 align:middle line:90% like that. 00:37:08.140 --> 00:37:09.250 align:middle line:90% Can he always do this? 00:37:09.250 --> 00:37:12.280 align:middle line:84% No, he needs to have this much time remaining, 00:37:12.280 --> 00:37:15.220 align:middle line:84% and he needs this much time in his bag-- 00:37:15.220 --> 00:37:20.218 align:middle line:84% or this much weight remaining in his bag. 00:37:20.218 --> 00:37:21.760 align:middle line:84% You guys can work out the inequality. 00:37:21.760 --> 00:37:23.177 align:middle line:84% But since I only have a foot here, 00:37:23.177 --> 00:37:25.060 align:middle line:90% I'll just say, if applicable. 00:37:25.060 --> 00:37:27.590 align:middle line:90% 00:37:27.590 --> 00:37:29.770 align:middle line:84% This is a great way to lose points on your homework. 00:37:29.770 --> 00:37:31.570 align:middle line:90% But for board-writing, it's OK. 00:37:31.570 --> 00:37:34.330 align:middle line:84% So when I say applicable, I mean these two numbers had better 00:37:34.330 --> 00:37:36.510 align:middle line:90% be greater than or equal to 0. 00:37:36.510 --> 00:37:37.440 align:middle line:90% OK? 00:37:37.440 --> 00:37:39.730 align:middle line:84% And you can do this for all k, right? 00:37:39.730 --> 00:37:43.150 align:middle line:84% So in other words, he can choose to get into booth k. 00:37:43.150 --> 00:37:46.690 align:middle line:84% And Tim has the third option, which is he can go home. 00:37:46.690 --> 00:37:47.260 align:middle line:90% OK? 00:37:47.260 --> 00:37:48.620 align:middle line:90% So what happens if he goes home? 00:37:48.620 --> 00:37:51.200 align:middle line:90% 00:37:51.200 --> 00:37:53.530 align:middle line:84% Does Tim the Beaver get cooler when he goes home? 00:37:53.530 --> 00:37:56.830 align:middle line:90% No, I'm afraid to say. 00:37:56.830 --> 00:38:00.010 align:middle line:90% 00:38:00.010 --> 00:38:02.110 align:middle line:90% But he does spend time. 00:38:02.110 --> 00:38:05.370 align:middle line:90% So how much time does he spend? 00:38:05.370 --> 00:38:05.870 align:middle line:90% h-- 00:38:05.870 --> 00:38:08.031 align:middle line:90% 00:38:08.031 --> 00:38:09.656 align:middle line:84% AUDIENCE: He should have lost coolness. 00:38:09.656 --> 00:38:10.906 align:middle line:90% JUSTIN SOLOMON: What was that? 00:38:10.906 --> 00:38:12.680 align:middle line:84% AUDIENCE: He should have lost coolness. 00:38:12.680 --> 00:38:15.320 align:middle line:84% JUSTIN SOLOMON: He should have lost coolness by going home. 00:38:15.320 --> 00:38:18.710 align:middle line:84% No, home is cool, guys, especially this semester. 00:38:18.710 --> 00:38:19.400 align:middle line:90% Stay home. 00:38:19.400 --> 00:38:21.630 align:middle line:90% Stay indoors. 00:38:21.630 --> 00:38:22.130 align:middle line:90% Right. 00:38:22.130 --> 00:38:26.830 align:middle line:84% So he loses home time h and 1 to get in the next line. 00:38:26.830 --> 00:38:28.310 align:middle line:90% OK? 00:38:28.310 --> 00:38:31.530 align:middle line:84% But he's got a devil's bargain, of sorts. 00:38:31.530 --> 00:38:36.590 align:middle line:84% He loses time, but he gains bag, bagginess. 00:38:36.590 --> 00:38:40.310 align:middle line:84% Weight is the word that I'm looking for, b, like that. 00:38:40.310 --> 00:38:41.720 align:middle line:90% OK? 00:38:41.720 --> 00:38:44.420 align:middle line:84% Again, in this case, remember that he still 00:38:44.420 --> 00:38:47.670 align:middle line:90% needs, if i is greater than h. 00:38:47.670 --> 00:38:50.680 align:middle line:90% Otherwise, he's in trouble. 00:38:50.680 --> 00:38:53.490 align:middle line:84% By the way, I wrote this in an annoying way. 00:38:53.490 --> 00:38:55.870 align:middle line:84% A different way of saying that is i minus h minus 1 00:38:55.870 --> 00:38:57.640 align:middle line:84% is greater than or equal to 0, which 00:38:57.640 --> 00:38:59.807 align:middle line:84% is really what's applicable in every recursive call. 00:38:59.807 --> 00:39:01.930 align:middle line:84% But this is strict greater than [INAUDIBLE].. 00:39:01.930 --> 00:39:03.250 align:middle line:84% There's another little thing that caught me up, when 00:39:03.250 --> 00:39:04.810 align:middle line:90% I was reading the answer here. 00:39:04.810 --> 00:39:07.100 align:middle line:84% OK, and those are all the options for Tim the Beaver, 00:39:07.100 --> 00:39:08.740 align:middle line:90% yeah? 00:39:08.740 --> 00:39:10.840 align:middle line:84% Notice that every one of our options 00:39:10.840 --> 00:39:16.070 align:middle line:84% either gives up completely or decreases time. 00:39:16.070 --> 00:39:19.270 align:middle line:84% So we have our topological order, 00:39:19.270 --> 00:39:21.910 align:middle line:84% which is, again, the arrow of time 00:39:21.910 --> 00:39:23.402 align:middle line:84% always continues to move forward. 00:39:23.402 --> 00:39:25.610 align:middle line:84% I'm going to prove that rigorously by putting a check 00:39:25.610 --> 00:39:28.450 align:middle line:84% mark next to the letter T. Again, on your homework, 00:39:28.450 --> 00:39:30.400 align:middle line:84% you should write out your answers. 00:39:30.400 --> 00:39:33.780 align:middle line:90% What is our base case for Tim? 00:39:33.780 --> 00:39:39.940 align:middle line:84% Well, how much coolness do you get, if you have no time? 00:39:39.940 --> 00:39:40.830 align:middle line:90% 0 coolness. 00:39:40.830 --> 00:39:42.610 align:middle line:90% That's how much. 00:39:42.610 --> 00:39:52.550 align:middle line:84% So we have this expression, x0j equals 0 for all j. 00:39:52.550 --> 00:39:54.990 align:middle line:84% Incidentally, although it's perfectly fine 00:39:54.990 --> 00:39:57.840 align:middle line:84% to have this be your base case, actually, in some sense, 00:39:57.840 --> 00:39:59.820 align:middle line:84% I didn't need it, because Tim the Beaver always 00:39:59.820 --> 00:40:01.315 align:middle line:90% had the option of giving up. 00:40:01.315 --> 00:40:02.940 align:middle line:84% So you could, I guess, in this problem, 00:40:02.940 --> 00:40:04.820 align:middle line:84% have no base case, if you really wanted. 00:40:04.820 --> 00:40:08.880 align:middle line:84% It would be OK, but kind of weird. 00:40:08.880 --> 00:40:10.697 align:middle line:90% OK. 00:40:10.697 --> 00:40:12.030 align:middle line:90% And what's our original problem? 00:40:12.030 --> 00:40:16.860 align:middle line:84% Well, he starts out with time k and weight capacity b 00:40:16.860 --> 00:40:17.880 align:middle line:90% in his bag. 00:40:17.880 --> 00:40:20.790 align:middle line:90% So it's x k, b. 00:40:20.790 --> 00:40:25.300 align:middle line:84% And then finally, we need to do our runtime analysis. 00:40:25.300 --> 00:40:26.890 align:middle line:84% So how many sub-problems are there? 00:40:26.890 --> 00:40:29.070 align:middle line:84% Well, again, a sub-problem is basically 00:40:29.070 --> 00:40:32.100 align:middle line:84% just the number of indexes for most of our dynamic programming 00:40:32.100 --> 00:40:33.010 align:middle line:90% problems. 00:40:33.010 --> 00:40:33.510 align:middle line:90% Right? 00:40:33.510 --> 00:40:38.450 align:middle line:90% So the first index is time. 00:40:38.450 --> 00:40:42.440 align:middle line:90% The second one is bag size. 00:40:42.440 --> 00:40:43.790 align:middle line:90% This is always between 0 and b. 00:40:43.790 --> 00:40:45.890 align:middle line:90% This is always between 0 and k. 00:40:45.890 --> 00:40:52.790 align:middle line:84% So there's order kb sub-problems. 00:40:52.790 --> 00:40:55.190 align:middle line:84% How much time does each sub-problem take? 00:40:55.190 --> 00:40:57.470 align:middle line:84% Well, notice that I have to loop over all 00:40:57.470 --> 00:40:59.910 align:middle line:90% of my different options k here. 00:40:59.910 --> 00:41:09.133 align:middle line:84% So I incur-- oh, I'm noticing k is abused in our answer 00:41:09.133 --> 00:41:09.800 align:middle line:90% to this problem. 00:41:09.800 --> 00:41:12.510 align:middle line:90% We should use k only once. 00:41:12.510 --> 00:41:15.518 align:middle line:84% OK, so here's where I made a mistake. 00:41:15.518 --> 00:41:17.310 align:middle line:84% And I believe it's in the written solution, 00:41:17.310 --> 00:41:18.932 align:middle line:90% but I'm not going to take now. 00:41:18.932 --> 00:41:21.570 align:middle line:84% There's k, which is the total time that Tim the Beaver has, 00:41:21.570 --> 00:41:24.210 align:middle line:84% and there's the k that I use as an index here. 00:41:24.210 --> 00:41:25.650 align:middle line:90% And those are not the same. 00:41:25.650 --> 00:41:30.320 align:middle line:84% I guess I can make this k bar really fast. 00:41:30.320 --> 00:41:32.510 align:middle line:90% There you go, problem solved. 00:41:32.510 --> 00:41:34.910 align:middle line:84% And I just noticed that, because I was doing my runtime. 00:41:34.910 --> 00:41:37.200 align:middle line:90% And it's not order k. 00:41:37.200 --> 00:41:40.940 align:middle line:84% It's the loop over all the k bars. 00:41:40.940 --> 00:41:42.390 align:middle line:90% How many k bars are there? 00:41:42.390 --> 00:41:44.098 align:middle line:84% Well, these are all the different booths, 00:41:44.098 --> 00:41:45.560 align:middle line:90% and those are n of those. 00:41:45.560 --> 00:41:51.410 align:middle line:84% So this is order n time per sub-problem, 00:41:51.410 --> 00:41:56.810 align:middle line:84% which gives me a total runtime of order kbn, which, 00:41:56.810 --> 00:41:58.390 align:middle line:90% I believe-- 00:41:58.390 --> 00:42:01.917 align:middle line:84% oh-oh, our desired runtime was order nbk. 00:42:01.917 --> 00:42:04.250 align:middle line:84% But I think we can convince ourselves that indeed, those 00:42:04.250 --> 00:42:05.870 align:middle line:90% are the same thing. 00:42:05.870 --> 00:42:10.320 align:middle line:84% OK, so my apologies for a slight overloaded character here. 00:42:10.320 --> 00:42:13.070 align:middle line:84% But honestly, it's one of those things, if you read the answer, 00:42:13.070 --> 00:42:14.487 align:middle line:84% you probably wouldn't even notice. 00:42:14.487 --> 00:42:16.910 align:middle line:84% But now that I'm saying it out loud, I am. 00:42:16.910 --> 00:42:17.450 align:middle line:90% OK. 00:42:17.450 --> 00:42:20.830 align:middle line:84% And that solves Tim the Beaver's maximization problem. 00:42:20.830 --> 00:42:22.460 align:middle line:90% He's a very cool Beaver. 00:42:22.460 --> 00:42:25.203 align:middle line:90% Any questions about this one? 00:42:25.203 --> 00:42:26.620 align:middle line:84% Notice that both of these problems 00:42:26.620 --> 00:42:28.140 align:middle line:90% are very similar in nature. 00:42:28.140 --> 00:42:29.710 align:middle line:84% I basically just wrote sub-problems 00:42:29.710 --> 00:42:32.680 align:middle line:84% indexed by every possible thing and then enumerated 00:42:32.680 --> 00:42:34.450 align:middle line:90% every possible solution. 00:42:34.450 --> 00:42:36.857 align:middle line:84% I think this is totally sensible. 00:42:36.857 --> 00:42:39.190 align:middle line:84% Again, I remember I had a math Professor in college that 00:42:39.190 --> 00:42:40.440 align:middle line:90% always would use this phrase-- 00:42:40.440 --> 00:42:42.280 align:middle line:84% it's important not to think here. 00:42:42.280 --> 00:42:44.195 align:middle line:84% And I think this is absolutely true 00:42:44.195 --> 00:42:45.820 align:middle line:84% for these dynamic programming problems, 00:42:45.820 --> 00:42:49.390 align:middle line:84% that somehow they look a lot more complicated than they are. 00:42:49.390 --> 00:42:50.570 align:middle line:90% Fabulous. 00:42:50.570 --> 00:42:54.730 align:middle line:90% So problem 3, protein parsing. 00:42:54.730 --> 00:42:59.020 align:middle line:84% Ah, yeah, so this one also got me tripped up for a minute. 00:42:59.020 --> 00:43:01.480 align:middle line:84% Because the runtime they want is not 00:43:01.480 --> 00:43:03.310 align:middle line:84% the runtime of the obvious solution, 00:43:03.310 --> 00:43:07.990 align:middle line:84% but it kind of, sort of is, after a little bit of fixing. 00:43:07.990 --> 00:43:09.280 align:middle line:90% OK. 00:43:09.280 --> 00:43:14.410 align:middle line:84% So Professor Leric Ander has a laboratory. 00:43:14.410 --> 00:43:18.032 align:middle line:84% And that laboratory processes DNA. 00:43:18.032 --> 00:43:20.004 align:middle line:90% Ta-da. 00:43:20.004 --> 00:43:22.270 align:middle line:84% OK, so let me go to my notes here, 00:43:22.270 --> 00:43:25.670 align:middle line:84% because I think they're easier to read. 00:43:25.670 --> 00:43:27.860 align:middle line:84% So a strand of DNA, as we all know, 00:43:27.860 --> 00:43:32.840 align:middle line:84% because we're MIT students, is equal to basically a strand 00:43:32.840 --> 00:43:36.260 align:middle line:90% of characters that are ACTG. 00:43:36.260 --> 00:43:39.680 align:middle line:84% If you ask me to name what those stood for, 00:43:39.680 --> 00:43:42.500 align:middle line:84% I could make a stab at one or two of them. 00:43:42.500 --> 00:43:44.870 align:middle line:90% But I'm a failure of-- 00:43:44.870 --> 00:43:47.430 align:middle line:84% I did not have the GIR, because I went to Stanford. 00:43:47.430 --> 00:43:51.200 align:middle line:84% And this is why I'm apparently a poorly educated person, 00:43:51.200 --> 00:43:54.140 align:middle line:84% according to a person in a faculty meeting. 00:43:54.140 --> 00:43:58.160 align:middle line:84% But in any event, so we have a strand of DNA. 00:43:58.160 --> 00:44:00.350 align:middle line:84% It's basically a long string of characters 00:44:00.350 --> 00:44:01.700 align:middle line:90% that are one of four options. 00:44:01.700 --> 00:44:03.860 align:middle line:84% I'm told that there's sometimes a fifth and a sixth option, 00:44:03.860 --> 00:44:04.670 align:middle line:90% but not too often. 00:44:04.670 --> 00:44:07.580 align:middle line:90% In this problem, there's not. 00:44:07.580 --> 00:44:12.030 align:middle line:84% And moreover, so a strand can be cut up. 00:44:12.030 --> 00:44:13.970 align:middle line:84% So I have this big, long strand, and I'm 00:44:13.970 --> 00:44:16.400 align:middle line:90% looking for certain markers. 00:44:16.400 --> 00:44:23.830 align:middle line:84% In particular, I have a list P of markers, 00:44:23.830 --> 00:44:30.220 align:middle line:84% which are really a sequence of less than or equal to k 00:44:30.220 --> 00:44:31.090 align:middle line:90% nucleotides. 00:44:31.090 --> 00:44:35.500 align:middle line:90% 00:44:35.500 --> 00:44:38.750 align:middle line:84% By the way, this really is something that people do. 00:44:38.750 --> 00:44:41.890 align:middle line:84% String searching really is applicable to processing 00:44:41.890 --> 00:44:42.760 align:middle line:90% these DNA strands. 00:44:42.760 --> 00:44:43.570 align:middle line:90% Obviously, . 00:44:43.570 --> 00:44:45.280 align:middle line:84% I think, in practice, these techniques 00:44:45.280 --> 00:44:48.010 align:middle line:84% have to be a lot more resilient to error. 00:44:48.010 --> 00:44:50.350 align:middle line:84% But really, a lot of these algorithms we're covering 00:44:50.350 --> 00:44:52.510 align:middle line:84% are not all that far off from how 00:44:52.510 --> 00:44:56.290 align:middle line:84% people process these giant data sets, which is pretty cool, 00:44:56.290 --> 00:44:57.850 align:middle line:90% I think. 00:44:57.850 --> 00:45:00.660 align:middle line:90% OK, so what are we going to do? 00:45:00.660 --> 00:45:02.273 align:middle line:90% We have a string. 00:45:02.273 --> 00:45:03.940 align:middle line:84% And then we're going to make a division. 00:45:03.940 --> 00:45:08.170 align:middle line:90% 00:45:08.170 --> 00:45:10.450 align:middle line:84% So we'll call our string S and our division 00:45:10.450 --> 00:45:16.750 align:middle line:84% D, which kind of looks like d1 to dm, 00:45:16.750 --> 00:45:21.220 align:middle line:84% which are substrings that concatenate 00:45:21.220 --> 00:45:23.642 align:middle line:90% to make the full guy. 00:45:23.642 --> 00:45:30.250 align:middle line:90% 00:45:30.250 --> 00:45:35.560 align:middle line:84% So if S is our input string, then a division D 00:45:35.560 --> 00:45:38.230 align:middle line:84% is just like chopping up S into little substrings, 00:45:38.230 --> 00:45:40.690 align:middle line:84% each of which we can give a name little d here. 00:45:40.690 --> 00:45:44.230 align:middle line:90% So big D is the full division. 00:45:44.230 --> 00:45:47.320 align:middle line:84% Little d is all the little pieces. 00:45:47.320 --> 00:45:49.547 align:middle line:84% There's that old song about going through the big D 00:45:49.547 --> 00:45:51.670 align:middle line:90% in [INAUDIBLE], Dallas. 00:45:51.670 --> 00:45:54.220 align:middle line:90% I think it's for divorce. 00:45:54.220 --> 00:46:02.970 align:middle line:84% Right, OK, so the value of a division 00:46:02.970 --> 00:46:05.820 align:middle line:90% is the number of strands. 00:46:05.820 --> 00:46:08.500 align:middle line:90% 00:46:08.500 --> 00:46:16.270 align:middle line:84% So strands are these little d's here, that are in our list P. 00:46:16.270 --> 00:46:19.090 align:middle line:90% OK? 00:46:19.090 --> 00:46:22.585 align:middle line:84% So given S and P, what we want is the max value. 00:46:22.585 --> 00:46:26.700 align:middle line:90% 00:46:26.700 --> 00:46:29.310 align:middle line:84% And the runtime that we're budgeted 00:46:29.310 --> 00:46:31.020 align:middle line:90% is kind of a weird runtime. 00:46:31.020 --> 00:46:33.540 align:middle line:84% And this should make us a little suspicious. 00:46:33.540 --> 00:46:38.460 align:middle line:90% So the max value is big O of-- 00:46:38.460 --> 00:46:41.210 align:middle line:84% I think I wrote it slightly differently in the problem, 00:46:41.210 --> 00:46:45.590 align:middle line:84% but whatever-- distributed to k, like that. 00:46:45.590 --> 00:46:48.980 align:middle line:84% So it's k mod P plus k squared. mod S. 00:46:48.980 --> 00:46:51.470 align:middle line:84% So we have two terms here, which somehow smells 00:46:51.470 --> 00:46:54.720 align:middle line:90% funny in dynamic programming. 00:46:54.720 --> 00:46:56.860 align:middle line:90% OK. 00:46:56.860 --> 00:46:58.280 align:middle line:90% So what are we to do? 00:46:58.280 --> 00:47:01.840 align:middle line:84% Well, what I did is I ignored our desired runtime, 00:47:01.840 --> 00:47:04.660 align:middle line:84% came up with a dynamic program, and noticed 00:47:04.660 --> 00:47:07.360 align:middle line:84% that it was a little wrong, and then fixed it. 00:47:07.360 --> 00:47:08.775 align:middle line:90% By wrong, I mean it was correct. 00:47:08.775 --> 00:47:10.460 align:middle line:90% It just wasn't fast enough. 00:47:10.460 --> 00:47:12.370 align:middle line:90% OK, so let's do version 1 here-- 00:47:12.370 --> 00:47:16.710 align:middle line:90% 00:47:16.710 --> 00:47:23.190 align:middle line:84% 1.0, that makes it more accurate, or more precise. 00:47:23.190 --> 00:47:25.480 align:middle line:90% I always confuse those two. 00:47:25.480 --> 00:47:29.078 align:middle line:84% So here's a thing that is going to be a little bit funny. 00:47:29.078 --> 00:47:30.620 align:middle line:84% Because it's going to look like we're 00:47:30.620 --> 00:47:32.960 align:middle line:84% going to have an easy computational problem. 00:47:32.960 --> 00:47:35.520 align:middle line:84% But then it's going to turn out that it's actually too slow. 00:47:35.520 --> 00:47:39.230 align:middle line:84% So in particular, in our S in SRTBOT, 00:47:39.230 --> 00:47:43.940 align:middle line:84% what we could do is say, xi is going 00:47:43.940 --> 00:47:50.430 align:middle line:90% to be the max value of a suffix. 00:47:50.430 --> 00:47:52.430 align:middle line:84% If you're wondering, I don't know the difference 00:47:52.430 --> 00:47:53.540 align:middle line:90% between prefix and suffix. 00:47:53.540 --> 00:47:55.165 align:middle line:84% But I wrote the word suffix in my notes 00:47:55.165 --> 00:47:57.050 align:middle line:90% and checked it at home. 00:47:57.050 --> 00:48:01.342 align:middle line:84% Si, comma, colon-- see, it's suffix, because it starts at i, 00:48:01.342 --> 00:48:02.300 align:middle line:90% and it goes to the end. 00:48:02.300 --> 00:48:03.200 align:middle line:90% AUDIENCE: [INAUDIBLE] 00:48:03.200 --> 00:48:04.033 align:middle line:90% JUSTIN SOLOMON: Huh? 00:48:04.033 --> 00:48:06.280 align:middle line:90% AUDIENCE: No comma. 00:48:06.280 --> 00:48:08.830 align:middle line:84% JUSTIN SOLOMON: In Matlab, it would be a comma. 00:48:08.830 --> 00:48:11.860 align:middle line:84% And that's a colon, and that's an i. 00:48:11.860 --> 00:48:12.400 align:middle line:90% OK. 00:48:12.400 --> 00:48:15.550 align:middle line:90% [LAUGHING] Thanks. 00:48:15.550 --> 00:48:17.800 align:middle line:84% I'm inventing my own programming language on the board 00:48:17.800 --> 00:48:19.540 align:middle line:90% as we go today. 00:48:19.540 --> 00:48:22.840 align:middle line:84% All right, so and notice this is a reasonable set 00:48:22.840 --> 00:48:23.890 align:middle line:90% of sub-problems, right? 00:48:23.890 --> 00:48:29.200 align:middle line:84% Because obviously, if I lop off some piece of my string, 00:48:29.200 --> 00:48:31.540 align:middle line:84% then the max value I can get is just 00:48:31.540 --> 00:48:33.580 align:middle line:90% the value of whatever remains. 00:48:33.580 --> 00:48:35.770 align:middle line:84% So spiritually, this somehow feels 00:48:35.770 --> 00:48:38.625 align:middle line:84% like the right dynamic programming. 00:48:38.625 --> 00:48:40.000 align:middle line:84% And indeed, we'll see that it is. 00:48:40.000 --> 00:48:41.740 align:middle line:84% But it just requires a little bit 00:48:41.740 --> 00:48:44.290 align:middle line:84% of a list that could be to run on the right time. 00:48:44.290 --> 00:48:45.280 align:middle line:90% OK? 00:48:45.280 --> 00:48:48.970 align:middle line:90% So let's do a recursive call. 00:48:48.970 --> 00:48:53.920 align:middle line:84% And this is actually straightforward. 00:48:53.920 --> 00:48:57.130 align:middle line:84% At least, the recursive call that you want to make 00:48:57.130 --> 00:48:57.950 align:middle line:90% is straightforward. 00:48:57.950 --> 00:49:00.010 align:middle line:84% And then we'll see that there is an equivalent formula, which 00:49:00.010 --> 00:49:01.843 align:middle line:84% is the one you'll see in the solution, which 00:49:01.843 --> 00:49:03.160 align:middle line:90% looks more complicated. 00:49:03.160 --> 00:49:04.340 align:middle line:90% But is the same thing. 00:49:04.340 --> 00:49:06.550 align:middle line:84% So I'm going to write it as pseudocode 00:49:06.550 --> 00:49:09.190 align:middle line:84% for our recursive call, rather than as one giant formula, 00:49:09.190 --> 00:49:10.877 align:middle line:84% because I think it's easier to follow. 00:49:10.877 --> 00:49:12.460 align:middle line:84% Not pseudocode-- I know that's frowned 00:49:12.460 --> 00:49:16.390 align:middle line:84% upon in this class, a description of a set of steps 00:49:16.390 --> 00:49:20.260 align:middle line:84% for obtaining a recursive call, rather than a formula. 00:49:20.260 --> 00:49:25.390 align:middle line:84% So in particular, we're going to initialize xi to be 0. 00:49:25.390 --> 00:49:29.080 align:middle line:90% 00:49:29.080 --> 00:49:30.770 align:middle line:84% We want to do a maximization problem. 00:49:30.770 --> 00:49:34.240 align:middle line:84% So initializing a variable to 0 is a sensible thing to do. 00:49:34.240 --> 00:49:35.990 align:middle line:84% And remember, what can we do here? 00:49:35.990 --> 00:49:37.480 align:middle line:90% So we're looking at a suffix. 00:49:37.480 --> 00:49:41.350 align:middle line:84% I could go down my list P of all the different markers, 00:49:41.350 --> 00:49:43.960 align:middle line:84% see if any of the matches the first couple of characters 00:49:43.960 --> 00:49:45.130 align:middle line:90% of my string. 00:49:45.130 --> 00:49:47.110 align:middle line:84% If it does, I get some value, and then I 00:49:47.110 --> 00:49:48.595 align:middle line:90% hop onto the next thing. 00:49:48.595 --> 00:49:49.620 align:middle line:90% Does that make sense? 00:49:49.620 --> 00:49:55.665 align:middle line:90% 00:49:55.665 --> 00:49:59.820 align:middle line:84% Oops, I'm realizing I have a slight mistake here. 00:49:59.820 --> 00:50:04.428 align:middle line:84% Rather than initializing to 0, [LAUGHING] 00:50:04.428 --> 00:50:05.970 align:middle line:84% I actually have one additional option 00:50:05.970 --> 00:50:07.110 align:middle line:90% that I forgot to account for. 00:50:07.110 --> 00:50:08.943 align:middle line:84% Because I could just not use this character. 00:50:08.943 --> 00:50:11.160 align:middle line:84% I could put it in its own little snippet 00:50:11.160 --> 00:50:12.970 align:middle line:90% and get no value from it. 00:50:12.970 --> 00:50:16.080 align:middle line:84% So maybe initially, I make a recursive call like that. 00:50:16.080 --> 00:50:18.150 align:middle line:84% It would be OK to initialize it to 0 00:50:18.150 --> 00:50:20.490 align:middle line:90% and then do this-- but whatever. 00:50:20.490 --> 00:50:22.790 align:middle line:84% Notice we're already seeing the t in our SRTBOT 00:50:22.790 --> 00:50:24.300 align:middle line:90% start to stick out at us. 00:50:24.300 --> 00:50:27.270 align:middle line:84% We're going to only depend on bigger indices i. 00:50:27.270 --> 00:50:28.380 align:middle line:90% OK. 00:50:28.380 --> 00:50:30.660 align:middle line:84% But in addition to this, this isn't enough, right? 00:50:30.660 --> 00:50:33.090 align:middle line:84% This would obviously just recurse the end of our list 00:50:33.090 --> 00:50:34.560 align:middle line:90% and do nothing. 00:50:34.560 --> 00:50:38.860 align:middle line:84% We get value if we can find a substring that's in our list. 00:50:38.860 --> 00:50:48.540 align:middle line:84% So what we could do is, for each marker in P-- 00:50:48.540 --> 00:50:50.960 align:middle line:84% remember P is the list of things that we're looking for-- 00:50:50.960 --> 00:50:54.350 align:middle line:90% 00:50:54.350 --> 00:50:57.800 align:middle line:90% OK, what could I do? 00:50:57.800 --> 00:51:08.960 align:middle line:84% If the marker matches S starting at i-- 00:51:08.960 --> 00:51:11.690 align:middle line:84% I'm going to just not even attempt to do Python-- 00:51:11.690 --> 00:51:17.560 align:middle line:84% starting at i and ending at the length of the marker, well, 00:51:17.560 --> 00:51:18.280 align:middle line:90% what could I do? 00:51:18.280 --> 00:51:25.170 align:middle line:84% I could get $1 by matching that object. 00:51:25.170 --> 00:51:27.843 align:middle line:84% And then I have to hop forward the length of the string 00:51:27.843 --> 00:51:29.010 align:middle line:90% in my recursive call, right? 00:51:29.010 --> 00:51:35.880 align:middle line:84% So well, I could do that, or I could not do that. 00:51:35.880 --> 00:51:37.290 align:middle line:90% And I want to maximize, right? 00:51:37.290 --> 00:51:45.440 align:middle line:84% So I can keep my old value, or I could get one point 00:51:45.440 --> 00:51:49.310 align:middle line:84% by using this as my match, plus xi 00:51:49.310 --> 00:51:53.580 align:middle line:90% plus the length of the marker. 00:51:53.580 --> 00:51:54.890 align:middle line:90% OK? 00:51:54.890 --> 00:51:57.020 align:middle line:84% This is actually, in my mind, the simplest 00:51:57.020 --> 00:51:59.280 align:middle line:84% possible dynamic program you could come up with. 00:51:59.280 --> 00:52:01.760 align:middle line:84% This is actually a totally fine dynamic program. 00:52:01.760 --> 00:52:03.843 align:middle line:84% We'll just see that the runtime isn't good enough. 00:52:03.843 --> 00:52:06.660 align:middle line:90% 00:52:06.660 --> 00:52:08.988 align:middle line:90% OK. 00:52:08.988 --> 00:52:10.530 align:middle line:84% So does everybody agree this is a way 00:52:10.530 --> 00:52:12.060 align:middle line:84% I could solve this problem, and it 00:52:12.060 --> 00:52:15.810 align:middle line:90% would give me a correct answer? 00:52:15.810 --> 00:52:17.970 align:middle line:90% I'll do the TBOT. 00:52:17.970 --> 00:52:18.845 align:middle line:90% AUDIENCE: [INAUDIBLE] 00:52:18.845 --> 00:52:21.012 align:middle line:84% JUSTIN SOLOMON: Yeah, that's what we're going to do. 00:52:21.012 --> 00:52:23.150 align:middle line:84% But we're going to maybe skip some parts of SRTBOT. 00:52:23.150 --> 00:52:26.760 align:middle line:84% So in particular, what's the topological order? 00:52:26.760 --> 00:52:29.600 align:middle line:84% Notice that I always look to the right, when I make a recursive 00:52:29.600 --> 00:52:31.430 align:middle line:90% call. 00:52:31.430 --> 00:52:33.030 align:middle line:90% What's my base case? 00:52:33.030 --> 00:52:37.040 align:middle line:84% Well, in this case, it's just a x of 0, I guess, 00:52:37.040 --> 00:52:38.540 align:middle line:90% because I'm looking forward. 00:52:38.540 --> 00:52:39.200 align:middle line:90% Oh, I'm sorry. 00:52:39.200 --> 00:52:42.050 align:middle line:84% My base case is x of the whole length of the string, which 00:52:42.050 --> 00:52:43.670 align:middle line:90% is going to return 0, right? 00:52:43.670 --> 00:52:47.090 align:middle line:84% Because if I have no string, I can't get any value out of it. 00:52:47.090 --> 00:52:51.240 align:middle line:84% The original is x of 0, meaning that I want the whole string. 00:52:51.240 --> 00:52:53.460 align:middle line:84% And let's actually do the runtime analysis, 00:52:53.460 --> 00:52:56.090 align:middle line:84% as Jason suggests, because that's, of course, 00:52:56.090 --> 00:52:59.920 align:middle line:90% the relevant computation here. 00:52:59.920 --> 00:53:05.730 align:middle line:84% So this is T2, because it's the second T in SRTBOT. 00:53:05.730 --> 00:53:10.580 align:middle line:84% OK, so how many sub-problems are there? 00:53:10.580 --> 00:53:13.082 align:middle line:84% Well, I mean, it almost looks like we 00:53:13.082 --> 00:53:14.290 align:middle line:90% should have a fast algorithm. 00:53:14.290 --> 00:53:18.100 align:middle line:84% Because our sub-problems are only indexed by i, right? 00:53:18.100 --> 00:53:22.000 align:middle line:84% So there's one sub-problem for basically each character 00:53:22.000 --> 00:53:23.020 align:middle line:90% in the string. 00:53:23.020 --> 00:53:26.260 align:middle line:84% So there's mod S sub-problems total. 00:53:26.260 --> 00:53:28.880 align:middle line:90% 00:53:28.880 --> 00:53:32.600 align:middle line:84% But how much time does it take for each sub-problem? , 00:53:32.600 --> 00:53:35.000 align:middle line:90% Well let's be careful. 00:53:35.000 --> 00:53:39.850 align:middle line:84% So there's a for loop over all the markers in P. 00:53:39.850 --> 00:53:47.620 align:middle line:84% So I know that I incur at least mod P work in my sub-problem. 00:53:47.620 --> 00:53:50.287 align:middle line:84% Is that all the work that I incur? 00:53:50.287 --> 00:53:52.370 align:middle line:84% It kind of looks like it, because there's only one 00:53:52.370 --> 00:53:53.537 align:middle line:90% for loop, and there's an if. 00:53:53.537 --> 00:53:55.260 align:middle line:84% But how do I check if strings are equal? 00:53:55.260 --> 00:53:58.200 align:middle line:84% Well, I have to iterate over the length of the string. 00:53:58.200 --> 00:54:01.160 align:middle line:84% So I incur a second cost, which is checking 00:54:01.160 --> 00:54:02.550 align:middle line:90% if two strings are equal. 00:54:02.550 --> 00:54:04.587 align:middle line:84% We know that our strings are at most-- 00:54:04.587 --> 00:54:06.170 align:middle line:84% well, I didn't actually write it down. 00:54:06.170 --> 00:54:08.000 align:middle line:84% But the problem tells us that our strings 00:54:08.000 --> 00:54:11.090 align:middle line:90% are at most length k. 00:54:11.090 --> 00:54:14.900 align:middle line:84% So I incur another factor of k in every one 00:54:14.900 --> 00:54:16.130 align:middle line:90% of my sub-problems. 00:54:16.130 --> 00:54:18.710 align:middle line:84% And that implies that our whole algorithm, 00:54:18.710 --> 00:54:25.150 align:middle line:84% that I've outlined for you all above, takes mod S k squared-- 00:54:25.150 --> 00:54:25.870 align:middle line:90% oh, I'm sorry. 00:54:25.870 --> 00:54:27.040 align:middle line:90% That was a lie. 00:54:27.040 --> 00:54:30.524 align:middle line:84% If I actually multiply these things together, what I get 00:54:30.524 --> 00:54:31.398 align:middle line:90% is-- sorry. 00:54:31.398 --> 00:54:33.430 align:middle line:90% [LAUGHING] I need more sleep-- 00:54:33.430 --> 00:54:35.440 align:middle line:90% S P k. 00:54:35.440 --> 00:54:37.180 align:middle line:90% And that is against the rules. 00:54:37.180 --> 00:54:40.740 align:middle line:90% So that's frowny face, yeah. 00:54:40.740 --> 00:54:43.540 align:middle line:84% Because in particular, I took two big numbers, in some sense, 00:54:43.540 --> 00:54:47.350 align:middle line:84% and multiplied them together, and that's not good. 00:54:47.350 --> 00:54:50.100 align:middle line:90% So what is a person to do? 00:54:50.100 --> 00:54:51.480 align:middle line:90% I tried to solve my problem. 00:54:51.480 --> 00:54:54.000 align:middle line:84% I came up with-- by the way, from a partial credit 00:54:54.000 --> 00:54:56.220 align:middle line:84% perspective, I think you'd be doing OK 00:54:56.220 --> 00:54:57.600 align:middle line:90% if you got to this point. 00:54:57.600 --> 00:55:00.900 align:middle line:90% OK, not great, but OK. 00:55:00.900 --> 00:55:03.210 align:middle line:84% But of course, the problem is asking 00:55:03.210 --> 00:55:06.510 align:middle line:84% you to solve this is this funny runtime, which 00:55:06.510 --> 00:55:11.500 align:middle line:90% is kP, plus k squared S. 00:55:11.500 --> 00:55:13.220 align:middle line:90% When I see a sum like this-- 00:55:13.220 --> 00:55:15.715 align:middle line:84% and remember that there are two problems to solve. 00:55:15.715 --> 00:55:17.590 align:middle line:84% There are two strategies for solving problems 00:55:17.590 --> 00:55:18.423 align:middle line:90% in algorithms class. 00:55:18.423 --> 00:55:20.950 align:middle line:84% There's one which is useful in your everyday lives, which 00:55:20.950 --> 00:55:22.690 align:middle line:90% is to devise algorithms. 00:55:22.690 --> 00:55:24.940 align:middle line:84% There's a second, which is to psychologically diagnose 00:55:24.940 --> 00:55:26.268 align:middle line:90% your instructors. 00:55:26.268 --> 00:55:28.810 align:middle line:84% And I think that second strategy is actually pretty effective 00:55:28.810 --> 00:55:29.310 align:middle line:90% here. 00:55:29.310 --> 00:55:30.430 align:middle line:90% I see two terms. 00:55:30.430 --> 00:55:32.088 align:middle line:84% Most of our dynamic programming things 00:55:32.088 --> 00:55:33.880 align:middle line:84% involve filling in a table, where you would 00:55:33.880 --> 00:55:35.840 align:middle line:90% expect there to be a product. 00:55:35.840 --> 00:55:39.790 align:middle line:84% So in general, I would squint at this and think, like, hm, maybe 00:55:39.790 --> 00:55:42.170 align:middle line:84% I have to do some pre-computation. 00:55:42.170 --> 00:55:43.160 align:middle line:90% Yeah? 00:55:43.160 --> 00:55:47.630 align:middle line:84% In particular, we've got to do a lot of string-matching 00:55:47.630 --> 00:55:52.490 align:middle line:84% in our problem, and maybe we can make that more efficient. 00:55:52.490 --> 00:55:53.020 align:middle line:90% Yeah? 00:55:53.020 --> 00:55:56.690 align:middle line:84% That's sort of the main question here. 00:55:56.690 --> 00:55:59.030 align:middle line:84% So this thing is too slow, and we're trying to fix it. 00:55:59.030 --> 00:56:00.950 align:middle line:84% The way I'm going to try and fix it 00:56:00.950 --> 00:56:05.422 align:middle line:84% is to say, like, OK, well, I have mod S sub-problems. 00:56:05.422 --> 00:56:07.380 align:middle line:84% If I look at these two terms, how much work can 00:56:07.380 --> 00:56:09.690 align:middle line:84% I actually do in my sub-problem, something 00:56:09.690 --> 00:56:12.560 align:middle line:84% that looks like k squared, maybe plus this amount 00:56:12.560 --> 00:56:13.540 align:middle line:90% of pre-computation. 00:56:13.540 --> 00:56:15.040 align:middle line:90% See what I did there? 00:56:15.040 --> 00:56:16.210 align:middle line:90% OK. 00:56:16.210 --> 00:56:19.510 align:middle line:90% So let's do that. 00:56:19.510 --> 00:56:21.410 align:middle line:84% So in particular, here are the types 00:56:21.410 --> 00:56:23.160 align:middle line:84% of queries that I'm going to have to make. 00:56:23.160 --> 00:56:26.580 align:middle line:90% 00:56:26.580 --> 00:56:29.580 align:middle line:84% There's a bunch of times in my code when-- 00:56:29.580 --> 00:56:30.930 align:middle line:90% here's a number that-- 00:56:30.930 --> 00:56:33.930 align:middle line:84% [HICCUPS] yikes, I'm falling apart. 00:56:33.930 --> 00:56:36.750 align:middle line:84% That's what I get for sprinting across campus to get here. 00:56:36.750 --> 00:56:41.280 align:middle line:84% I'm going to find a number m i, j. 00:56:41.280 --> 00:56:47.835 align:middle line:84% And it's going to be 1 if the substring S i-- 00:56:47.835 --> 00:56:57.741 align:middle line:84% oh, man-- to j is in my list of markers P, and 0 otherwise. 00:56:57.741 --> 00:57:00.900 align:middle line:90% 00:57:00.900 --> 00:57:02.430 align:middle line:90% By the way, why is this enough? 00:57:02.430 --> 00:57:05.070 align:middle line:84% Notice that I'm not answering, which marker? 00:57:05.070 --> 00:57:07.300 align:middle line:84% But the problem doesn't really care, right? 00:57:07.300 --> 00:57:09.330 align:middle line:84% This problem just checks if there is a marker. 00:57:09.330 --> 00:57:11.988 align:middle line:84% And if so, then I use that, yeah. 00:57:11.988 --> 00:57:13.530 align:middle line:84% So if I have this thing, that's going 00:57:13.530 --> 00:57:15.438 align:middle line:84% to somehow make this for loop a heck of a lot 00:57:15.438 --> 00:57:17.730 align:middle line:84% easier, because now I don't have to do string-matching. 00:57:17.730 --> 00:57:19.810 align:middle line:84% We'll return to that in a minute. 00:57:19.810 --> 00:57:21.340 align:middle line:90% OK. 00:57:21.340 --> 00:57:24.790 align:middle line:84% So my question is, how can I compute this thing? 00:57:24.790 --> 00:57:30.030 align:middle line:84% And by the way, notice that I know 00:57:30.030 --> 00:57:33.060 align:middle line:84% how to compute this when the difference between i and j 00:57:33.060 --> 00:57:36.870 align:middle line:84% is bigger than k, because I know that all of my markers 00:57:36.870 --> 00:57:38.510 align:middle line:90% have length k or less. 00:57:38.510 --> 00:57:40.260 align:middle line:84% That's going to be important, because even 00:57:40.260 --> 00:57:44.980 align:middle line:84% though m is doubly indexed, I don't actually need to do that. 00:57:44.980 --> 00:57:47.543 align:middle line:84% In fact, I could even store it using less memory 00:57:47.543 --> 00:57:48.960 align:middle line:84% than that, if I wanted to, by just 00:57:48.960 --> 00:57:51.240 align:middle line:90% storing that diagonal block. 00:57:51.240 --> 00:57:54.855 align:middle line:90% OK, right. 00:57:54.855 --> 00:57:56.230 align:middle line:84% So the other thing, which I think 00:57:56.230 --> 00:57:58.180 align:middle line:84% we saw in a previous problem session, as well, 00:57:58.180 --> 00:58:00.013 align:middle line:84% is that when we do a lot of string-matching, 00:58:00.013 --> 00:58:03.670 align:middle line:84% it often pays to put our strings into a hash table, 00:58:03.670 --> 00:58:05.500 align:middle line:84% so that they're easier to look up later. 00:58:05.500 --> 00:58:08.040 align:middle line:84% Does this string exist in this thing or not? 00:58:08.040 --> 00:58:11.210 align:middle line:84% Rather than matching every character every single time. 00:58:11.210 --> 00:58:14.836 align:middle line:84% So maybe we do that, just for fun. 00:58:14.836 --> 00:58:17.272 align:middle line:84% And in general, when you see a string-matching problem-- 00:58:17.272 --> 00:58:18.730 align:middle line:84% and you have a list of strings, I'd 00:58:18.730 --> 00:58:20.188 align:middle line:84% suggest thinking about hash tables, 00:58:20.188 --> 00:58:21.960 align:middle line:90% just for fun and profit. 00:58:21.960 --> 00:58:27.520 align:middle line:84% So in step one here, maybe I put all the strings in P 00:58:27.520 --> 00:58:28.150 align:middle line:90% into a hash. 00:58:28.150 --> 00:58:32.420 align:middle line:90% 00:58:32.420 --> 00:58:33.782 align:middle line:90% OK? 00:58:33.782 --> 00:58:34.990 align:middle line:90% How much time does that take? 00:58:34.990 --> 00:58:39.207 align:middle line:84% Well, I have to process every string, find its code, 00:58:39.207 --> 00:58:40.790 align:middle line:84% which is going to take more of k time. 00:58:40.790 --> 00:58:46.880 align:middle line:84% There's mod P of them, so this is k mod P time. 00:58:46.880 --> 00:58:49.550 align:middle line:84% Notice that that conveniently agrees with our first term 00:58:49.550 --> 00:58:50.050 align:middle line:90% here. 00:58:50.050 --> 00:58:52.410 align:middle line:84% So we feel like, aha, we're in good shape. 00:58:52.410 --> 00:58:54.710 align:middle line:90% We're making progress here. 00:58:54.710 --> 00:59:01.130 align:middle line:84% And now, maybe I want to fill in this m, i, j objects here. 00:59:01.130 --> 00:59:04.050 align:middle line:90% How could I do that? 00:59:04.050 --> 00:59:07.250 align:middle line:84% Well, for one, I'm certainly going to iterate over all 00:59:07.250 --> 00:59:08.220 align:middle line:90% possible i's. 00:59:08.220 --> 00:59:08.720 align:middle line:90% OK? 00:59:08.720 --> 00:59:10.530 align:middle line:90% So let's do that. 00:59:10.530 --> 00:59:12.410 align:middle line:90% So we're going to do 2. 00:59:12.410 --> 00:59:15.162 align:middle line:84% By the way, I'm using 1's and 2's and a's and b's 00:59:15.162 --> 00:59:15.870 align:middle line:90% and the whatever. 00:59:15.870 --> 00:59:18.230 align:middle line:84% These are just ways to denote steps of things. 00:59:18.230 --> 00:59:24.330 align:middle line:84% [LAUGHING] OK, so let's say that I just 00:59:24.330 --> 00:59:27.690 align:middle line:84% want to fill in m using a brain-dead algorithm. 00:59:27.690 --> 00:59:33.350 align:middle line:84% So I could go from 1 to the size of my strings for i. 00:59:33.350 --> 00:59:33.950 align:middle line:90% Careful. 00:59:33.950 --> 00:59:37.070 align:middle line:90% Now I can't incur an S squared. 00:59:37.070 --> 00:59:40.770 align:middle line:84% But I know that my strings are always at mostly k. 00:59:40.770 --> 00:59:51.900 align:middle line:84% So I could do for j equals i plus 1 to i plus k. 00:59:51.900 --> 00:59:56.050 align:middle line:84% So this for loop actually incurs k time, not mod S time. 00:59:56.050 --> 00:59:58.450 align:middle line:90% And now I can do two things. 00:59:58.450 --> 01:00:06.270 align:middle line:84% I can find the hash of the string from i to j. 01:00:06.270 --> 01:00:10.470 align:middle line:84% This is going to take order k time. 01:00:10.470 --> 01:00:15.250 align:middle line:90% And I can search for it-- 01:00:15.250 --> 01:00:29.360 align:middle line:84% ah, no-- to see if it's actually in our hash table of P. 01:00:29.360 --> 01:00:31.760 align:middle line:84% And if it is, then I set m equal to 1. 01:00:31.760 --> 01:00:33.440 align:middle line:90% Otherwise, I set m equal to 0. 01:00:33.440 --> 01:00:37.700 align:middle line:90% 01:00:37.700 --> 01:00:39.890 align:middle line:84% And these are constant time operations, 01:00:39.890 --> 01:00:41.630 align:middle line:90% at least in expectation. 01:00:41.630 --> 01:00:43.710 align:middle line:90% So how much cost to it? 01:00:43.710 --> 01:00:47.135 align:middle line:84% And so this, you can convince yourself fills in that array m. 01:00:47.135 --> 01:00:48.260 align:middle line:90% How much time does it take? 01:00:48.260 --> 01:00:53.900 align:middle line:84% Well, I have a loop to the size of S. I have a loop of size k. 01:00:53.900 --> 01:00:57.460 align:middle line:84% I have a second loop of size k here to compute the hash. 01:00:57.460 --> 01:01:01.885 align:middle line:84% So this whole thing is going to take order k squared mod 01:01:01.885 --> 01:01:04.540 align:middle line:90% S time, like that. 01:01:04.540 --> 01:01:08.390 align:middle line:84% Now, this conveniently-- there's chalk on the floor. 01:01:08.390 --> 01:01:11.180 align:middle line:84% And this is the second term in our runtime. 01:01:11.180 --> 01:01:12.140 align:middle line:90% So this is kosher. 01:01:12.140 --> 01:01:13.370 align:middle line:90% We can fill in m. 01:01:13.370 --> 01:01:16.700 align:middle line:84% And that's a convenient object to have around. 01:01:16.700 --> 01:01:18.290 align:middle line:84% So the only thing that remains is 01:01:18.290 --> 01:01:24.170 align:middle line:84% to revise our R from above, to make use of the m that we have. 01:01:24.170 --> 01:01:25.978 align:middle line:84% And that's pretty straightforward. 01:01:25.978 --> 01:01:30.560 align:middle line:90% 01:01:30.560 --> 01:01:33.310 align:middle line:84% So the trick is to not lean against this thing 01:01:33.310 --> 01:01:34.970 align:middle line:84% and to actually hit the stop button. 01:01:34.970 --> 01:01:36.230 align:middle line:90% I'm learning. 01:01:36.230 --> 01:01:43.350 align:middle line:84% So now I suppose we had T2 for the second T. So for revised R, 01:01:43.350 --> 01:01:46.008 align:middle line:90% we should have R prime. 01:01:46.008 --> 01:01:47.872 align:middle line:90% [LAUGHING] 01:01:47.872 --> 01:01:48.810 align:middle line:90% AUDIENCE: [INAUDIBLE] 01:01:48.810 --> 01:01:49.290 align:middle line:90% JUSTIN SOLOMON: What was that? 01:01:49.290 --> 01:01:50.910 align:middle line:90% AUDIENCE: The deriviative. 01:01:50.910 --> 01:01:51.270 align:middle line:90% JUSTIN SOLOMON: That's right. 01:01:51.270 --> 01:01:53.820 align:middle line:84% The derivative-- yeah, we could do Christoffel symbols, 01:01:53.820 --> 01:01:56.210 align:middle line:84% like i, j prime, and semicolon k. 01:01:56.210 --> 01:01:59.100 align:middle line:90% 01:01:59.100 --> 01:02:04.740 align:middle line:84% Take 6838 if you want to learn what Christoffel symbols are. 01:02:04.740 --> 01:02:10.500 align:middle line:84% Right, so now, what is my recursive call for xi? 01:02:10.500 --> 01:02:12.360 align:middle line:90% Well, I want to maximize. 01:02:12.360 --> 01:02:15.310 align:middle line:90% 01:02:15.310 --> 01:02:16.430 align:middle line:90% Well, what can I do? 01:02:16.430 --> 01:02:18.130 align:middle line:84% I can check every possible length 01:02:18.130 --> 01:02:22.450 align:middle line:84% of a string that could be in P, check 01:02:22.450 --> 01:02:27.570 align:middle line:84% if it is, using my array m, and get that amount of profit. 01:02:27.570 --> 01:02:30.043 align:middle line:90% So in particular, I get m. 01:02:30.043 --> 01:02:31.960 align:middle line:84% By the way, I keep using the word profit here. 01:02:31.960 --> 01:02:34.390 align:middle line:84% I am essentially using that to mean increment 01:02:34.390 --> 01:02:36.160 align:middle line:84% in every single one of our problems here. 01:02:36.160 --> 01:02:38.650 align:middle line:84% I like to think of our problems as maximizing profit, 01:02:38.650 --> 01:02:40.270 align:middle line:90% because I'm a greedy professor. 01:02:40.270 --> 01:02:45.370 align:middle line:84% So this is m, i j, which would be 1 if I found a string there 01:02:45.370 --> 01:02:52.510 align:middle line:84% and 0 if I'm not, plus xi plus j, to account for the length 01:02:52.510 --> 01:02:58.300 align:middle line:90% here, where j is in 1 to-- 01:02:58.300 --> 01:03:02.200 align:middle line:84% well, either the length of the string, 01:03:02.200 --> 01:03:04.090 align:middle line:90% or I get to the end of-- 01:03:04.090 --> 01:03:06.310 align:middle line:84% either the maximum length of a string in P, 01:03:06.310 --> 01:03:11.220 align:middle line:84% or I get to the end of my array, like that. 01:03:11.220 --> 01:03:11.720 align:middle line:90% OK. 01:03:11.720 --> 01:03:13.440 align:middle line:84% And this is our new recursive call. 01:03:13.440 --> 01:03:14.940 align:middle line:84% The one thing we should double-check 01:03:14.940 --> 01:03:18.120 align:middle line:84% is, what is the runtime for actually filling in x now? 01:03:18.120 --> 01:03:22.270 align:middle line:84% Well, there's still the mod S sub-problems. 01:03:22.270 --> 01:03:24.950 align:middle line:90% And now how long does it take? 01:03:24.950 --> 01:03:27.820 align:middle line:84% Well, now I just have one loop over k things. 01:03:27.820 --> 01:03:29.680 align:middle line:90% This is mod S times k. 01:03:29.680 --> 01:03:31.780 align:middle line:84% It's actually less than any of the terms that's 01:03:31.780 --> 01:03:34.460 align:middle line:90% in our runtime. 01:03:34.460 --> 01:03:35.410 align:middle line:90% And so this is fine. 01:03:35.410 --> 01:03:37.570 align:middle line:84% This actually is kind of a funny example, 01:03:37.570 --> 01:03:41.170 align:middle line:84% where the dynamic programming part of our algorithm, 01:03:41.170 --> 01:03:43.330 align:middle line:84% once we've done all this cute pre-computation, 01:03:43.330 --> 01:03:46.240 align:middle line:84% is actually insignificant, compared to all 01:03:46.240 --> 01:03:49.240 align:middle line:84% the pre-computation that we had to do in our final runtime-- 01:03:49.240 --> 01:03:51.120 align:middle line:90% sneaky. 01:03:51.120 --> 01:03:53.550 align:middle line:84% All right, any questions about protein folding, 01:03:53.550 --> 01:03:55.710 align:middle line:84% or whatever it is that we just did? 01:03:55.710 --> 01:03:57.030 align:middle line:90% OK. 01:03:57.030 --> 01:03:58.480 align:middle line:84% So as usual, I'm talking too much. 01:03:58.480 --> 01:03:59.520 align:middle line:90% AUDIENCE: [INAUDIBLE]? 01:03:59.520 --> 01:04:01.050 align:middle line:84% JUSTIN SOLOMON: Yeah, which one would you prefer to cut? 01:04:01.050 --> 01:04:01.990 align:middle line:90% AUDIENCE: [INAUDIBLE] 01:04:01.990 --> 01:04:06.690 align:middle line:84% JUSTIN SOLOMON: I have very few preferences. 01:04:06.690 --> 01:04:09.150 align:middle line:90% OK, so one of your problems-- 01:04:09.150 --> 01:04:12.210 align:middle line:84% I would take a vote, but with our audience, 01:04:12.210 --> 01:04:16.390 align:middle line:84% there's is a high probability of a split on jury here. 01:04:16.390 --> 01:04:16.890 align:middle line:90% Right. 01:04:16.890 --> 01:04:18.000 align:middle line:84% So there's two remaining problems 01:04:18.000 --> 01:04:18.958 align:middle line:90% on the problem session. 01:04:18.958 --> 01:04:20.940 align:middle line:90% As usual, your instructor-- 01:04:20.940 --> 01:04:21.895 align:middle line:90% AUDIENCE: [INAUDIBLE] 01:04:21.895 --> 01:04:23.520 align:middle line:84% JUSTIN SOLOMON: You can leave it there. 01:04:23.520 --> 01:04:27.000 align:middle line:84% This is another problem to learn about. 01:04:27.000 --> 01:04:30.210 align:middle line:84% As usual, I've talked too much and haven't got to the end. 01:04:30.210 --> 01:04:33.030 align:middle line:84% I get the impression that in 6006, this egg drop thing 01:04:33.030 --> 01:04:35.193 align:middle line:90% is a bit of a tradition anyway. 01:04:35.193 --> 01:04:37.110 align:middle line:84% So maybe we'll cover that problem really fast. 01:04:37.110 --> 01:04:39.060 align:middle line:84% Do they do that in section, some variation? 01:04:39.060 --> 01:04:39.360 align:middle line:90% AUDIENCE: No. 01:04:39.360 --> 01:04:40.652 align:middle line:90% JUSTIN SOLOMON: Not this time-- 01:04:40.652 --> 01:04:41.890 align:middle line:90% even better. 01:04:41.890 --> 01:04:44.977 align:middle line:84% OK, so yes, so maybe we'll do this egg-drop thing, 01:04:44.977 --> 01:04:46.560 align:middle line:84% mostly because the other one, I think, 01:04:46.560 --> 01:04:48.840 align:middle line:90% takes a lot of verbal setup. 01:04:48.840 --> 01:04:51.570 align:middle line:90% The other one is-- 01:04:51.570 --> 01:04:54.180 align:middle line:84% I would say, from a dynamic programming perspective, maybe 01:04:54.180 --> 01:04:55.140 align:middle line:90% not super exciting. 01:04:55.140 --> 01:04:57.690 align:middle line:84% But from an interesting problem perspective, 01:04:57.690 --> 01:05:00.380 align:middle line:84% it's kind of cool to think about. 01:05:00.380 --> 01:05:02.130 align:middle line:84% So I'd encourage you to leave it in there, 01:05:02.130 --> 01:05:04.830 align:middle line:84% and you guys can read it at home. 01:05:04.830 --> 01:05:06.920 align:middle line:84% From a coding perspective, it's also kind of fun. 01:05:06.920 --> 01:05:08.920 align:middle line:84% I notice the solution didn't do what I would do, 01:05:08.920 --> 01:05:11.800 align:middle line:84% which would be to use the bits in the-- 01:05:11.800 --> 01:05:13.530 align:middle line:84% assume that something wasn't too tall, 01:05:13.530 --> 01:05:18.080 align:middle line:84% use the bits in an integer to store your binary variables. 01:05:18.080 --> 01:05:19.520 align:middle line:90% But that's an old hack. 01:05:19.520 --> 01:05:21.803 align:middle line:84% That's like this old hack for computing 01:05:21.803 --> 01:05:23.720 align:middle line:84% the square root of a number, that's apparently 01:05:23.720 --> 01:05:27.260 align:middle line:84% in the code for the Doom video game, which involves 01:05:27.260 --> 01:05:30.140 align:middle line:84% bit-shifting, and it happens to agree with square root, 01:05:30.140 --> 01:05:35.000 align:middle line:84% for some magic reason, that numerical analysts really hate. 01:05:35.000 --> 01:05:38.940 align:middle line:84% OK, so let's do lazy egg drop instead. 01:05:38.940 --> 01:05:41.420 align:middle line:90% So that's problem 4. 01:05:41.420 --> 01:05:43.820 align:middle line:90% OK. 01:05:43.820 --> 01:05:46.000 align:middle line:90% So we're in a building. 01:05:46.000 --> 01:05:51.690 align:middle line:84% Our building has n floors and k eggs. 01:05:51.690 --> 01:05:54.212 align:middle line:90% 01:05:54.212 --> 01:05:56.170 align:middle line:84% I guess it's debatable whether the building has 01:05:56.170 --> 01:05:58.780 align:middle line:84% eggs or the residents-- but in any event, 01:05:58.780 --> 01:06:01.000 align:middle line:90% have some set of eggs. 01:06:01.000 --> 01:06:02.530 align:middle line:84% And maybe I'm in this data center 01:06:02.530 --> 01:06:03.740 align:middle line:90% or some other weird building. 01:06:03.740 --> 01:06:08.470 align:middle line:84% So I don't have heights of floors that are isotropic, 01:06:08.470 --> 01:06:10.972 align:middle line:84% but rather, each floor has a different height, 01:06:10.972 --> 01:06:11.680 align:middle line:90% which could vary. 01:06:11.680 --> 01:06:15.040 align:middle line:90% 01:06:15.040 --> 01:06:20.060 align:middle line:90% So it's height of floor, or i. 01:06:20.060 --> 01:06:24.650 align:middle line:84% I really want to write flour, but I digress. 01:06:24.650 --> 01:06:28.753 align:middle line:84% And we're going to assume that our list is already sorted. 01:06:28.753 --> 01:06:30.170 align:middle line:84% So in other words, the fifth floor 01:06:30.170 --> 01:06:32.330 align:middle line:84% is taller than the fourth floor, and we 01:06:32.330 --> 01:06:36.710 align:middle line:84% don't have to spend n log-in time doing that. 01:06:36.710 --> 01:06:37.770 align:middle line:90% OK. 01:06:37.770 --> 01:06:38.270 align:middle line:90% Right. 01:06:38.270 --> 01:06:42.410 align:middle line:84% So apparently, in our problem, we 01:06:42.410 --> 01:06:44.810 align:middle line:84% have an egg with a mysterious mechanical property 01:06:44.810 --> 01:06:47.900 align:middle line:90% that we are trying to recover. 01:06:47.900 --> 01:06:51.260 align:middle line:84% And all eggs, as we know, are identical. 01:06:51.260 --> 01:06:54.830 align:middle line:84% So the only difference between eggs is chicken, versus goose, 01:06:54.830 --> 01:06:55.940 align:middle line:90% versus-- 01:06:55.940 --> 01:06:58.860 align:middle line:84% I'm struggling to think of a third category of poultry-- 01:06:58.860 --> 01:06:59.360 align:middle line:90% turkey. 01:06:59.360 --> 01:07:01.640 align:middle line:90% Thank you. 01:07:01.640 --> 01:07:03.518 align:middle line:84% But assuming that I got all of my eggs 01:07:03.518 --> 01:07:05.060 align:middle line:84% at the same Stop-N-Shop, and they all 01:07:05.060 --> 01:07:06.770 align:middle line:84% come from the same species, then they 01:07:06.770 --> 01:07:08.930 align:middle line:84% have roughly the same mechanical properties. 01:07:08.930 --> 01:07:10.400 align:middle line:84% Actually, probably the better setup 01:07:10.400 --> 01:07:12.150 align:middle line:84% is that floors are very far apart relative 01:07:12.150 --> 01:07:14.990 align:middle line:90% to the size of an egg. 01:07:14.990 --> 01:07:17.690 align:middle line:84% And if I get high enough, my egg, 01:07:17.690 --> 01:07:22.998 align:middle line:84% when I drop them on the ground, like that, breaks. 01:07:22.998 --> 01:07:23.540 align:middle line:90% Didn't break. 01:07:23.540 --> 01:07:25.100 align:middle line:90% But it could have broken. 01:07:25.100 --> 01:07:28.310 align:middle line:84% And of course, if I drop it from an even higher height, 01:07:28.310 --> 01:07:30.860 align:middle line:90% my egg still is going to break. 01:07:30.860 --> 01:07:33.050 align:middle line:84% However, if I have a very low floor-- apparently, 01:07:33.050 --> 01:07:33.800 align:middle line:90% a very low floor. 01:07:33.800 --> 01:07:37.490 align:middle line:90% Maybe this is a house for mice. 01:07:37.490 --> 01:07:40.280 align:middle line:84% And I drop my egg, it actually stays intact. 01:07:40.280 --> 01:07:43.790 align:middle line:84% And the question, as all good scientists want to know, 01:07:43.790 --> 01:07:46.760 align:middle line:84% is, what is the highest floor in my building from which I 01:07:46.760 --> 01:07:51.460 align:middle line:84% can drop an egg and have it remain intact? 01:07:51.460 --> 01:07:56.500 align:middle line:84% And the question is kind of a funny one. 01:07:56.500 --> 01:07:59.460 align:middle line:84% It's sort of like experimental design, in some sense. 01:07:59.460 --> 01:08:05.130 align:middle line:84% It's not asking, given this and a list of experiments, try 01:08:05.130 --> 01:08:07.500 align:middle line:84% and figure, infer, something about the eggs. 01:08:07.500 --> 01:08:10.830 align:middle line:84% But rather, it's saying, if I carefully 01:08:10.830 --> 01:08:15.560 align:middle line:84% design a sequence of floors to drop my eggs from, 01:08:15.560 --> 01:08:22.170 align:middle line:84% from which upon I drop my eggs, then 01:08:22.170 --> 01:08:24.630 align:middle line:84% what is the maximum number of experiments 01:08:24.630 --> 01:08:28.380 align:middle line:84% I need to do to triangulate in on that floor, 01:08:28.380 --> 01:08:32.770 align:middle line:84% that critical floor, above which my eggs break? 01:08:32.770 --> 01:08:34.920 align:middle line:84% So what I'm given are the heights of the floors 01:08:34.920 --> 01:08:36.340 align:middle line:90% and a bunch of eggs. 01:08:36.340 --> 01:08:39.609 align:middle line:84% In some sense, the budget of eggs 01:08:39.609 --> 01:08:42.819 align:middle line:84% doesn't matter more than just putting a cap on the size 01:08:42.819 --> 01:08:44.750 align:middle line:90% of our problem, in some sense. 01:08:44.750 --> 01:08:47.109 align:middle line:84% What really matters is I'd like to use fewer than k eggs 01:08:47.109 --> 01:08:48.147 align:middle line:90% to determine that. 01:08:48.147 --> 01:08:49.689 align:middle line:84% Because of course, the remaining ones 01:08:49.689 --> 01:08:52.609 align:middle line:84% I'm going to use to make an omelet. 01:08:52.609 --> 01:08:54.410 align:middle line:84% But notice that I can be a little 01:08:54.410 --> 01:08:58.219 align:middle line:84% sneaky in my experimental design, 01:08:58.219 --> 01:09:02.279 align:middle line:84% that what happens if I drop my egg from a really 01:09:02.279 --> 01:09:04.620 align:middle line:90% low floor in my building? 01:09:04.620 --> 01:09:06.790 align:middle line:90% Well, it remains intact. 01:09:06.790 --> 01:09:09.310 align:middle line:90% So I can schlep down the stairs. 01:09:09.310 --> 01:09:11.910 align:middle line:84% I can pick up my egg, and I can use it for my next experiment. 01:09:11.910 --> 01:09:15.520 align:middle line:90% And I have not paid an egg. 01:09:15.520 --> 01:09:17.710 align:middle line:90% Yeah? 01:09:17.710 --> 01:09:19.390 align:middle line:84% So the first question you might ask 01:09:19.390 --> 01:09:22.520 align:middle line:84% is, like, well, why the heck wouldn't I just 01:09:22.520 --> 01:09:24.510 align:middle line:84% start on the first floor, drop the egg. 01:09:24.510 --> 01:09:27.625 align:middle line:84% If it's not broken, go on to the next one 01:09:27.625 --> 01:09:29.000 align:middle line:84% and then drop the egg, and so on? 01:09:29.000 --> 01:09:32.040 align:middle line:84% That would be the most egg-efficient plan. 01:09:32.040 --> 01:09:34.040 align:middle line:84% And indeed that is the case, because you'll only 01:09:34.040 --> 01:09:35.960 align:middle line:90% break at most one egg. 01:09:35.960 --> 01:09:38.297 align:middle line:84% But you're schlepping up and down the stairs 01:09:38.297 --> 01:09:40.130 align:middle line:84% a bunch of times when you solve that, right? 01:09:40.130 --> 01:09:44.353 align:middle line:84% Every single time, you've got to go retrieve that unbroken egg. 01:09:44.353 --> 01:09:45.770 align:middle line:84% You've got to run down the stairs, 01:09:45.770 --> 01:09:47.978 align:middle line:84% pick the thing up, and then run up to the next floor. 01:09:47.978 --> 01:09:50.540 align:middle line:84% And maybe in your optimization problem, 01:09:50.540 --> 01:09:52.830 align:middle line:84% rather than trying to minimize the number of eggs 01:09:52.830 --> 01:09:56.600 align:middle line:84% that you break, you're trying to minimize the expense 01:09:56.600 --> 01:09:57.800 align:middle line:90% on your quads. 01:09:57.800 --> 01:10:03.020 align:middle line:84% And so instead, you've skipped your leg day, or whatever, 01:10:03.020 --> 01:10:05.630 align:middle line:84% and the thing that you're trying to minimize 01:10:05.630 --> 01:10:14.600 align:middle line:84% is the sum over the heights of the drops in your experiments. 01:10:14.600 --> 01:10:18.340 align:middle line:84% So you're trying to determine the mechanical property 01:10:18.340 --> 01:10:21.580 align:middle line:84% of your egg by designing an experiment, sort 01:10:21.580 --> 01:10:24.340 align:middle line:84% of a procedure, that minimizes the number of times 01:10:24.340 --> 01:10:26.325 align:middle line:90% that you need to drop eggs. 01:10:26.325 --> 01:10:27.700 align:middle line:84% Because every time you do, you've 01:10:27.700 --> 01:10:29.080 align:middle line:84% got to run all the way back down the stairs, 01:10:29.080 --> 01:10:31.622 align:middle line:84% and go look at the pavement, and see if the egg broke or not. 01:10:31.622 --> 01:10:32.620 align:middle line:90% That's a lot of work. 01:10:32.620 --> 01:10:33.610 align:middle line:90% OK. 01:10:33.610 --> 01:10:36.910 align:middle line:84% This is different from the classic egg-drop 6006 problem, 01:10:36.910 --> 01:10:38.980 align:middle line:84% which I encourage you guys to go seek out, 01:10:38.980 --> 01:10:42.310 align:middle line:84% in previous iterations of this course. 01:10:42.310 --> 01:10:44.680 align:middle line:90% Let me see. 01:10:44.680 --> 01:10:50.170 align:middle line:84% And so the question is, what is the minimum number of egg drops 01:10:50.170 --> 01:10:54.610 align:middle line:84% you need to do to ascertain that for any type of egg-- 01:10:54.610 --> 01:10:56.740 align:middle line:84% so I give you a mystery basket of eggs, 01:10:56.740 --> 01:10:59.230 align:middle line:84% and you have to design the experimental procedure 01:10:59.230 --> 01:11:03.280 align:middle line:84% and bound the number of this particular value here, 01:11:03.280 --> 01:11:05.830 align:middle line:90% given a budget of k eggs. 01:11:05.830 --> 01:11:07.030 align:middle line:90% OK. 01:11:07.030 --> 01:11:13.690 align:middle line:84% And the amount of time that we have to do that is order n 01:11:13.690 --> 01:11:16.070 align:middle line:90% cubed k. 01:11:16.070 --> 01:11:18.020 align:middle line:84% Apparently, our building, we have 01:11:18.020 --> 01:11:20.760 align:middle line:84% lots of eggs and not very many floors. 01:11:20.760 --> 01:11:21.860 align:middle line:90% OK. 01:11:21.860 --> 01:11:23.563 align:middle line:84% Does our setup make some sense here? 01:11:23.563 --> 01:11:25.980 align:middle line:84% We're just trying to avoid running up and down the stairs. 01:11:25.980 --> 01:11:28.070 align:middle line:90% That's the main takeaway. 01:11:28.070 --> 01:11:29.930 align:middle line:90% OK. 01:11:29.930 --> 01:11:31.730 align:middle line:90% So what are we going to do? 01:11:31.730 --> 01:11:34.430 align:middle line:84% SRTBOT, because that's all we know how to do, yeah? 01:11:34.430 --> 01:11:37.550 align:middle line:84% And in particular, we're going to make one observation, which 01:11:37.550 --> 01:11:38.810 align:middle line:90% is kind of handy. 01:11:38.810 --> 01:11:40.900 align:middle line:90% If I drop a floor-- 01:11:40.900 --> 01:11:45.600 align:middle line:84% ooh, if I drop an egg from a floor, 01:11:45.600 --> 01:11:49.290 align:middle line:84% in this deterministic universe, where egg mechanics are 01:11:49.290 --> 01:11:51.850 align:middle line:84% very predictable, there's only one 01:11:51.850 --> 01:11:53.100 align:middle line:90% of two things that can happen. 01:11:53.100 --> 01:11:56.310 align:middle line:84% Either the egg broke or it didn't, 01:11:56.310 --> 01:11:58.900 align:middle line:84% while I run into the board again. 01:11:58.900 --> 01:12:01.467 align:middle line:84% So let's think about our experiment. 01:12:01.467 --> 01:12:03.050 align:middle line:84% Remember, at the end of the day, we're 01:12:03.050 --> 01:12:07.340 align:middle line:84% trying to figure out the tallest floor in my building 01:12:07.340 --> 01:12:10.910 align:middle line:84% from which I can safely drop an egg. 01:12:10.910 --> 01:12:17.095 align:middle line:84% So if I think about bracketing that height of that floor, 01:12:17.095 --> 01:12:18.720 align:middle line:84% for one thing, do I ever need a bracket 01:12:18.720 --> 01:12:23.370 align:middle line:84% that's not a continuous or a connected set of numbers? 01:12:23.370 --> 01:12:24.420 align:middle line:90% The answer is no, right? 01:12:24.420 --> 01:12:26.782 align:middle line:84% It should never be the case that, like, oh, 01:12:26.782 --> 01:12:29.588 align:middle line:84% I think that my eggs could be on floors one-- 01:12:29.588 --> 01:12:32.130 align:middle line:84% only the prime number of floors in my building, or something. 01:12:32.130 --> 01:12:33.547 align:middle line:84% That really makes no sense, right? 01:12:33.547 --> 01:12:36.900 align:middle line:84% Because if I convince myself my egg breaks at four or five, 01:12:36.900 --> 01:12:40.270 align:middle line:84% then obviously, floors six through n, my egg also breaks. 01:12:40.270 --> 01:12:44.610 align:middle line:84% And so I always can just keep narrowing down some interval. 01:12:44.610 --> 01:12:45.660 align:middle line:90% Right? 01:12:45.660 --> 01:12:49.020 align:middle line:84% So in particular, here's a clever S 01:12:49.020 --> 01:12:53.960 align:middle line:84% in my SRTBOT, which is to say that I'm 01:12:53.960 --> 01:13:04.060 align:middle line:84% going to say that x, i, j, e is equal to the minimum-- 01:13:04.060 --> 01:13:07.288 align:middle line:84% by the way, I'm writing this as minimum total height. 01:13:07.288 --> 01:13:09.580 align:middle line:84% So this is the minimum total times I've got to run down 01:13:09.580 --> 01:13:13.360 align:middle line:84% the stairs and check my eggs, or total height that I run down 01:13:13.360 --> 01:13:17.200 align:middle line:84% the stair-- the number of stairs I run down, 01:13:17.200 --> 01:13:21.160 align:middle line:84% assuming my stairs are 1 foot tall-- 01:13:21.160 --> 01:13:24.220 align:middle line:90% where I have e eggs left. 01:13:24.220 --> 01:13:26.827 align:middle line:90% 01:13:26.827 --> 01:13:29.160 align:middle line:84% Notice the way that we've written the problem this time, 01:13:29.160 --> 01:13:31.150 align:middle line:84% I might as well use all of my k eggs. 01:13:31.150 --> 01:13:32.400 align:middle line:90% That doesn't cost me anything. 01:13:32.400 --> 01:13:35.970 align:middle line:84% What costs me is running up and down the stairs. 01:13:35.970 --> 01:13:44.610 align:middle line:84% And that I have floors i through j inclusive to check. 01:13:44.610 --> 01:13:47.070 align:middle line:84% So in other words, if I'm on a floor below floor i, 01:13:47.070 --> 01:13:49.380 align:middle line:84% I've convinced myself my egg won't break. 01:13:49.380 --> 01:13:51.480 align:middle line:84% But if I'm on a a floor above floor j, 01:13:51.480 --> 01:13:54.130 align:middle line:90% I'm convinced my egg will break. 01:13:54.130 --> 01:13:55.090 align:middle line:90% OK? 01:13:55.090 --> 01:13:57.560 align:middle line:90% So what do I do? 01:13:57.560 --> 01:14:00.400 align:middle line:84% Well, remember that this is an experimental design problem. 01:14:00.400 --> 01:14:14.110 align:middle line:84% I can drop my egg from any floor f, which is in the range i 01:14:14.110 --> 01:14:15.607 align:middle line:90% to j. 01:14:15.607 --> 01:14:17.440 align:middle line:84% And of course, there's never a reason for me 01:14:17.440 --> 01:14:20.350 align:middle line:84% to drop an egg from a floor below i or above j, 01:14:20.350 --> 01:14:22.900 align:middle line:84% because we already know what happens in that case. 01:14:22.900 --> 01:14:24.700 align:middle line:90% OK? 01:14:24.700 --> 01:14:29.320 align:middle line:90% So what happens when we do that? 01:14:29.320 --> 01:14:31.950 align:middle line:84% Well, if I drop it from floor f, I 01:14:31.950 --> 01:14:34.980 align:middle line:84% have to pay, in terms of my cost function, right? 01:14:34.980 --> 01:14:39.300 align:middle line:84% Because to pay the height of f, I've got run down the stairs. 01:14:39.300 --> 01:14:41.670 align:middle line:90% OK? 01:14:41.670 --> 01:14:45.690 align:middle line:84% But in exchange for that, I learn a little bit 01:14:45.690 --> 01:14:46.740 align:middle line:90% about my egg problem. 01:14:46.740 --> 01:14:49.030 align:middle line:84% I either get an upper or a lower bound of f, 01:14:49.030 --> 01:14:50.950 align:middle line:84% depending on whether the egg broke. 01:14:50.950 --> 01:14:51.450 align:middle line:90% OK? 01:14:51.450 --> 01:14:55.240 align:middle line:84% So let's formalize that mathematically. 01:14:55.240 --> 01:14:59.916 align:middle line:84% So in particular, we have x i, j, e. 01:14:59.916 --> 01:15:02.720 align:middle line:90% 01:15:02.720 --> 01:15:05.840 align:middle line:84% Well, what do I get to control in my life? 01:15:05.840 --> 01:15:08.160 align:middle line:90% And what do I have to deal with? 01:15:08.160 --> 01:15:09.910 align:middle line:84% Well, what I have to deal with is the fact 01:15:09.910 --> 01:15:11.040 align:middle line:84% that I don't know what's going to happen to the egg. 01:15:11.040 --> 01:15:11.665 align:middle line:90% It might break. 01:15:11.665 --> 01:15:12.540 align:middle line:90% It might not. 01:15:12.540 --> 01:15:13.040 align:middle line:90% Right? 01:15:13.040 --> 01:15:15.020 align:middle line:84% And the egg might be an adversarial egg-- 01:15:15.020 --> 01:15:17.090 align:middle line:84% it wants you to run up and down the stairs. 01:15:17.090 --> 01:15:19.080 align:middle line:90% And I have to account for that. 01:15:19.080 --> 01:15:22.070 align:middle line:84% But i and the egg's adversary need 01:15:22.070 --> 01:15:24.660 align:middle line:84% to choose what floor I drop it from. 01:15:24.660 --> 01:15:27.410 align:middle line:90% So remember, we saw an example. 01:15:27.410 --> 01:15:29.778 align:middle line:84% I forget what, from class, where there was a game. 01:15:29.778 --> 01:15:31.070 align:middle line:90% One guy was trying to minimize. 01:15:31.070 --> 01:15:33.320 align:middle line:84% The other was trying to maximize. 01:15:33.320 --> 01:15:38.000 align:middle line:84% In some sense, the egg is trying to maximize the amount of work 01:15:38.000 --> 01:15:41.540 align:middle line:84% you have to do, running up and down the stairs to do 01:15:41.540 --> 01:15:42.360 align:middle line:90% your experiment. 01:15:42.360 --> 01:15:43.860 align:middle line:84% A better way to put it is that we're 01:15:43.860 --> 01:15:45.680 align:middle line:84% trying to upper bound the amount of work 01:15:45.680 --> 01:15:47.840 align:middle line:90% in your experimental procedure. 01:15:47.840 --> 01:15:49.670 align:middle line:84% And I'm trying to design a procedure that 01:15:49.670 --> 01:15:50.935 align:middle line:90% minimizes my work. 01:15:50.935 --> 01:15:52.310 align:middle line:84% So let's say that I'm the player. 01:15:52.310 --> 01:15:55.230 align:middle line:90% So I want to minimize. 01:15:55.230 --> 01:16:00.530 align:middle line:84% And the decision that I get to make, the control that I have, 01:16:00.530 --> 01:16:01.560 align:middle line:90% is what? 01:16:01.560 --> 01:16:04.230 align:middle line:90% Well, it's what floor I choose. 01:16:04.230 --> 01:16:06.212 align:middle line:90% So let's say I choose floor f. 01:16:06.212 --> 01:16:07.670 align:middle line:84% Well, I have to go down the stairs. 01:16:07.670 --> 01:16:09.672 align:middle line:90% So that takes me hf. 01:16:09.672 --> 01:16:11.380 align:middle line:84% This was going up the stairs, is probably 01:16:11.380 --> 01:16:13.940 align:middle line:84% what incurs the hf going down is nothing. 01:16:13.940 --> 01:16:15.640 align:middle line:90% But I digress. 01:16:15.640 --> 01:16:18.850 align:middle line:90% But now I still am not done. 01:16:18.850 --> 01:16:21.790 align:middle line:84% I've narrowed it down into one of two cases, right? 01:16:21.790 --> 01:16:24.415 align:middle line:84% Either f is my new lower bound or my new upper bound. 01:16:24.415 --> 01:16:27.460 align:middle line:84% And I have to account for both of those in my recursion 01:16:27.460 --> 01:16:30.160 align:middle line:84% and actually, the max of those two, in the sense 01:16:30.160 --> 01:16:33.430 align:middle line:84% that I need, in every possible case, 01:16:33.430 --> 01:16:35.620 align:middle line:84% that my egg drop experiment narrows down 01:16:35.620 --> 01:16:39.280 align:middle line:90% my floor to a width of 0. 01:16:39.280 --> 01:16:43.060 align:middle line:84% So in particular, this is a mini-max problem. 01:16:43.060 --> 01:16:46.610 align:middle line:84% There's a max inside of of a min here. 01:16:46.610 --> 01:16:50.720 align:middle line:84% So either the egg broke in my experiment or it didn't. 01:16:50.720 --> 01:16:51.320 align:middle line:90% Right? 01:16:51.320 --> 01:16:55.660 align:middle line:84% So if it did broke, then, well, what happened? 01:16:55.660 --> 01:16:57.970 align:middle line:90% Well, let's see here. 01:16:57.970 --> 01:17:01.312 align:middle line:84% If the egg broke, then I got an upper bound for my floor. 01:17:01.312 --> 01:17:02.770 align:middle line:84% So my lower bound remains the same. 01:17:02.770 --> 01:17:04.090 align:middle line:90% It's i. 01:17:04.090 --> 01:17:09.390 align:middle line:84% My upper bound is f minus 1, because it broke on floor f. 01:17:09.390 --> 01:17:12.420 align:middle line:84% Well, what happens to eggs when they break? 01:17:12.420 --> 01:17:14.920 align:middle line:84% I can't drop them from floors again. 01:17:14.920 --> 01:17:17.320 align:middle line:90% So I lost an egg. 01:17:17.320 --> 01:17:19.200 align:middle line:90% OK? 01:17:19.200 --> 01:17:24.540 align:middle line:90% So this is my egg broke. 01:17:24.540 --> 01:17:25.470 align:middle line:90% OK? 01:17:25.470 --> 01:17:27.830 align:middle line:90% Or my egg didn't break. 01:17:27.830 --> 01:17:31.430 align:middle line:84% So in that case, well, if my egg did break, 01:17:31.430 --> 01:17:34.280 align:middle line:90% now I have a lower bound. 01:17:34.280 --> 01:17:37.940 align:middle line:84% So I'm only unclear about floors f plus 1. 01:17:37.940 --> 01:17:40.370 align:middle line:84% But the upper bound didn't change. 01:17:40.370 --> 01:17:42.420 align:middle line:90% It's still j. 01:17:42.420 --> 01:17:43.587 align:middle line:90% And how many eggs do I have? 01:17:43.587 --> 01:17:45.420 align:middle line:84% Well, my egg didn't break, so I can run down 01:17:45.420 --> 01:17:47.250 align:middle line:84% the stairs, which is going to be tiring, 01:17:47.250 --> 01:17:48.665 align:middle line:90% I've accounted for that here. 01:17:48.665 --> 01:17:50.040 align:middle line:84% But at least I can re-use my egg. 01:17:50.040 --> 01:17:52.860 align:middle line:90% So I didn't lose anything. 01:17:52.860 --> 01:17:54.490 align:middle line:90% OK? 01:17:54.490 --> 01:17:57.830 align:middle line:90% And I get to choose. 01:17:57.830 --> 01:18:01.030 align:middle line:84% So notice-- oops-- so do you guys 01:18:01.030 --> 01:18:02.240 align:middle line:90% see why there's a max here? 01:18:02.240 --> 01:18:05.470 align:middle line:84% Essentially, I have to account for every possible scenario 01:18:05.470 --> 01:18:09.130 align:middle line:84% when I'm designing my experimental procedure. 01:18:09.130 --> 01:18:10.728 align:middle line:84% But I get to minimize, in the sense 01:18:10.728 --> 01:18:12.520 align:middle line:84% that I can choose what floor at every step. 01:18:12.520 --> 01:18:23.810 align:middle line:84% So in particular, my f here is in the range i to j, like that. 01:18:23.810 --> 01:18:25.670 align:middle line:84% OK, and now we have our recursive formula 01:18:25.670 --> 01:18:29.400 align:middle line:84% for our egg drop that minimizes total height. 01:18:29.400 --> 01:18:32.000 align:middle line:84% So now let's finish off SRTBOT in four minutes. 01:18:32.000 --> 01:18:33.570 align:middle line:90% It's actually not too hard. 01:18:33.570 --> 01:18:34.945 align:middle line:84% So I think we'll actually make it 01:18:34.945 --> 01:18:37.960 align:middle line:84% for once by removing 20% of the problems I 01:18:37.960 --> 01:18:40.910 align:middle line:90% was supposed to cover. 01:18:40.910 --> 01:18:41.410 align:middle line:90% All right. 01:18:41.410 --> 01:18:47.420 align:middle line:90% 01:18:47.420 --> 01:18:51.710 align:middle line:84% So first of all, what's our topological order? 01:18:51.710 --> 01:18:57.460 align:middle line:84% So this one seems kind of annoying. 01:18:57.460 --> 01:19:00.550 align:middle line:84% Because I think usually, we think 01:19:00.550 --> 01:19:04.730 align:middle line:84% of spending stuff in a lot of these dynamic programming 01:19:04.730 --> 01:19:05.230 align:middle line:90% problems. 01:19:05.230 --> 01:19:06.563 align:middle line:90% But do we actually spend an egg? 01:19:06.563 --> 01:19:07.720 align:middle line:90% Not necessarily, right? 01:19:07.720 --> 01:19:12.910 align:middle line:84% Because in this recursive call, the number of eggs 01:19:12.910 --> 01:19:14.090 align:middle line:90% I had remained the same. 01:19:14.090 --> 01:19:16.780 align:middle line:84% So maybe that's not actually a great way to establish 01:19:16.780 --> 01:19:18.400 align:middle line:90% a topological order. 01:19:18.400 --> 01:19:20.500 align:middle line:90% But instead, what do we know? 01:19:20.500 --> 01:19:24.040 align:middle line:84% What is in science the purpose of an experiment? 01:19:24.040 --> 01:19:27.290 align:middle line:84% It's to improve our understanding of the world. 01:19:27.290 --> 01:19:29.500 align:middle line:84% In this case, our world consists only 01:19:29.500 --> 01:19:31.583 align:middle line:90% of eggs and floors of buildings. 01:19:31.583 --> 01:19:33.250 align:middle line:84% And in particular, once I drop that egg, 01:19:33.250 --> 01:19:34.750 align:middle line:84% I learn something about my building. 01:19:34.750 --> 01:19:37.300 align:middle line:84% And I narrowed down the range of floors 01:19:37.300 --> 01:19:38.830 align:middle line:90% that are uncertain for me. 01:19:38.830 --> 01:19:43.548 align:middle line:84% So in particular, I know that x i, 01:19:43.548 --> 01:19:57.200 align:middle line:84% j, e only depends on x, I guess, i prime, j prime, e prime, 01:19:57.200 --> 01:19:58.520 align:middle line:90% with what? 01:19:58.520 --> 01:20:01.550 align:middle line:84% Well, my sub-problems, I always have a smaller range of flaws 01:20:01.550 --> 01:20:02.880 align:middle line:90% than I did before. 01:20:02.880 --> 01:20:06.320 align:middle line:84% So in particular, j prime minus i 01:20:06.320 --> 01:20:10.970 align:middle line:84% prime is going to be smaller strictly than j minus i. 01:20:10.970 --> 01:20:15.450 align:middle line:84% And that'll give me my topological order. 01:20:15.450 --> 01:20:16.420 align:middle line:90% Cool. 01:20:16.420 --> 01:20:19.180 align:middle line:84% And so that's actually, I think, the sort of annoying part, 01:20:19.180 --> 01:20:21.940 align:middle line:84% other than working out this mini-max expression here. 01:20:21.940 --> 01:20:24.560 align:middle line:84% The remaining things are not so hard. 01:20:24.560 --> 01:20:26.800 align:middle line:90% So what are our base cases? 01:20:26.800 --> 01:20:31.970 align:middle line:84% Well, let's say I have 0 eggs left. 01:20:31.970 --> 01:20:34.460 align:middle line:84% But I still have a set of uncertain floors. 01:20:34.460 --> 01:20:36.410 align:middle line:90% That's bad news. 01:20:36.410 --> 01:20:38.120 align:middle line:90% Yeah? 01:20:38.120 --> 01:20:42.210 align:middle line:84% Yeah, so that should be infinity. 01:20:42.210 --> 01:20:47.960 align:middle line:84% And the reason is, of course, I'm going to take the min here. 01:20:47.960 --> 01:20:48.500 align:middle line:90% Right? 01:20:48.500 --> 01:20:51.877 align:middle line:84% And so obviously, I should never choose infinity as a min. 01:20:51.877 --> 01:20:53.960 align:middle line:84% So in other words, I should never choose an option 01:20:53.960 --> 01:20:56.180 align:middle line:84% for a floor that could possibly lead me 01:20:56.180 --> 01:21:01.550 align:middle line:84% to an uncertain scenario, when I run out of eggs, yeah? 01:21:01.550 --> 01:21:04.970 align:middle line:84% In addition to that, there's another base case here. 01:21:04.970 --> 01:21:07.885 align:middle line:84% This is I've got no eggs left, but some floors to check, 01:21:07.885 --> 01:21:15.000 align:middle line:90% is the second one, i minus 1e. 01:21:15.000 --> 01:21:18.330 align:middle line:84% So in this case, I've got e eggs left, and I'm done, right? 01:21:18.330 --> 01:21:21.588 align:middle line:84% I've narrowed it down to the bounds. 01:21:21.588 --> 01:21:23.880 align:middle line:84% Incidentally, the way I wrote it in terms of inclusive, 01:21:23.880 --> 01:21:27.230 align:middle line:84% versus exclusive, might be a little fishy. 01:21:27.230 --> 01:21:29.060 align:middle line:84% Over here, you guys shouldn't be off by 1, 01:21:29.060 --> 01:21:31.280 align:middle line:90% like your instructor often is. 01:21:31.280 --> 01:21:33.578 align:middle line:84% But in any event, here, you're 0, right? 01:21:33.578 --> 01:21:35.120 align:middle line:84% There's no more floors left to check. 01:21:35.120 --> 01:21:37.500 align:middle line:84% You've narrowed it down to a range of 1. 01:21:37.500 --> 01:21:39.060 align:middle line:84% Again, something that I'm out of time 01:21:39.060 --> 01:21:40.560 align:middle line:84% so I'm not going to check carefully, 01:21:40.560 --> 01:21:44.270 align:middle line:84% is if my bounds are inclusive, should that be i, j minus 1-- 01:21:44.270 --> 01:21:45.742 align:middle line:90% i minus 1 or just i, i? 01:21:45.742 --> 01:21:47.450 align:middle line:84% But I think you guys are all smart enough 01:21:47.450 --> 01:21:49.530 align:middle line:90% to work that out at home,. 01:21:49.530 --> 01:21:52.640 align:middle line:84% Which would my original case be, well, now I 01:21:52.640 --> 01:21:55.940 align:middle line:84% have all the floors to check, and all my eggs 01:21:55.940 --> 01:21:58.430 align:middle line:90% in my metaphorical basket here. 01:21:58.430 --> 01:22:04.940 align:middle line:90% So I have floors 1 to n here. 01:22:04.940 --> 01:22:09.050 align:middle line:84% And the problem tells me I have k eggs when I start. 01:22:09.050 --> 01:22:16.020 align:middle line:84% And then finally, I need to do my sub-problems here. 01:22:16.020 --> 01:22:18.690 align:middle line:84% I think you can actually simplify the argument that's 01:22:18.690 --> 01:22:20.490 align:middle line:90% written down a tiny bit. 01:22:20.490 --> 01:22:22.690 align:middle line:84% And just again, look at your sub-problems. 01:22:22.690 --> 01:22:25.520 align:middle line:84% They're indexed by three numbers, 01:22:25.520 --> 01:22:27.480 align:middle line:84% I'm going to do a really conservative estimate. 01:22:27.480 --> 01:22:29.855 align:middle line:84% I think the problem actually works out a better estimate, 01:22:29.855 --> 01:22:33.030 align:middle line:84% but then asymptotically, it's the same. 01:22:33.030 --> 01:22:35.360 align:middle line:84% What's our bound on the first and second index? 01:22:35.360 --> 01:22:37.640 align:middle line:84% Well, they're both just the index 01:22:37.640 --> 01:22:41.730 align:middle line:84% of floors, which go between 0 and n. 01:22:41.730 --> 01:22:42.230 align:middle line:90% Yeah? 01:22:42.230 --> 01:22:44.330 align:middle line:84% Obviously, you could do better than that, because the lower 01:22:44.330 --> 01:22:46.455 align:middle line:84% floor is always less than the upper floor, which is 01:22:46.455 --> 01:22:47.930 align:middle line:90% what the problem accounts for. 01:22:47.930 --> 01:22:52.400 align:middle line:84% But if I'm being lazy, then, well, there's 01:22:52.400 --> 01:22:57.470 align:middle line:84% n squared sub-problems to account for the two floors. 01:22:57.470 --> 01:23:00.560 align:middle line:84% And the third index is your eggs, 01:23:00.560 --> 01:23:03.650 align:middle line:90% which you have at most k of. 01:23:03.650 --> 01:23:08.960 align:middle line:84% OK, how much work do we have per sub-problem? 01:23:08.960 --> 01:23:11.030 align:middle line:90% Well, let's see here. 01:23:11.030 --> 01:23:13.175 align:middle line:90% There's a for loop over f. 01:23:13.175 --> 01:23:14.510 align:middle line:90% f Is over floors. 01:23:14.510 --> 01:23:17.150 align:middle line:84% Again, if I'm going to be really conservative, 01:23:17.150 --> 01:23:22.860 align:middle line:84% well, there's at most n floors total in my building. 01:23:22.860 --> 01:23:27.200 align:middle line:84% And so that leads us to a runtime and n cubed k, 01:23:27.200 --> 01:23:29.780 align:middle line:84% which is what we wanted, at the end of the day. 01:23:29.780 --> 01:23:30.280 align:middle line:90% OK? 01:23:30.280 --> 01:23:33.230 align:middle line:90% 01:23:33.230 --> 01:23:35.690 align:middle line:84% This should be a big O here, because I think technically, 01:23:35.690 --> 01:23:39.740 align:middle line:84% this is n plus 1, to account for floor zero. 01:23:39.740 --> 01:23:42.490 align:middle line:90% OK. 01:23:42.490 --> 01:23:46.075 align:middle line:84% And that solves our egg-drop experiment. 01:23:46.075 --> 01:23:47.200 align:middle line:90% I think this is a nice one. 01:23:47.200 --> 01:23:48.700 align:middle line:84% And I think, in my mind, actually, 01:23:48.700 --> 01:23:50.242 align:middle line:84% in terms of dynamic programming, this 01:23:50.242 --> 01:23:52.510 align:middle line:84% is one of the harder things to get right, 01:23:52.510 --> 01:23:57.315 align:middle line:90% which are these mini-max games. 01:23:57.315 --> 01:23:58.690 align:middle line:84% I'd have to think about it, which 01:23:58.690 --> 01:24:02.800 align:middle line:84% in my negative two minutes, I'm not going to have time to do. 01:24:02.800 --> 01:24:06.962 align:middle line:84% I think in lecture, the way that we solve minimize problem 01:24:06.962 --> 01:24:08.670 align:middle line:84% was we separated out the min and the max, 01:24:08.670 --> 01:24:11.100 align:middle line:84% and we thought of there being two dynamic programming 01:24:11.100 --> 01:24:13.110 align:middle line:84% problems that are interacting with each other. 01:24:13.110 --> 01:24:15.870 align:middle line:84% You could probably write this one in that form, as well, 01:24:15.870 --> 01:24:18.240 align:middle line:84% I guess, just by pulling this term out and thinking 01:24:18.240 --> 01:24:21.210 align:middle line:90% of it as a different array. 01:24:21.210 --> 01:24:22.800 align:middle line:84% But this form is perfectly fine, too. 01:24:22.800 --> 01:24:23.550 align:middle line:90% Either one's all right. 01:24:23.550 --> 01:24:25.530 align:middle line:84% But in my mind, these are the hardest things 01:24:25.530 --> 01:24:27.230 align:middle line:84% to get right in dynamic programming. 01:24:27.230 --> 01:24:30.840 align:middle line:84% So I would choose whichever one jives in your brain. 01:24:30.840 --> 01:24:34.750 align:middle line:84% So in your thing, should we choose to leave it alone? 01:24:34.750 --> 01:24:37.140 align:middle line:84% There is a fifth problem here, which, as usual, 01:24:37.140 --> 01:24:40.740 align:middle line:84% I haven't managed to get to, where you're building walls 01:24:40.740 --> 01:24:41.560 align:middle line:90% by placing tiles. 01:24:41.560 --> 01:24:43.560 align:middle line:84% This is an interesting one, because your runtime 01:24:43.560 --> 01:24:45.150 align:middle line:90% is exponential. 01:24:45.150 --> 01:24:47.970 align:middle line:84% But the problem tells you that that's allowed. 01:24:47.970 --> 01:24:50.130 align:middle line:84% But there's some exponential things which are OK 01:24:50.130 --> 01:24:51.510 align:middle line:90% and some that are not. 01:24:51.510 --> 01:24:53.610 align:middle line:84% Essentially, what you don't want is the product 01:24:53.610 --> 01:24:54.840 align:middle line:90% of two giant exponentials. 01:24:54.840 --> 01:24:57.000 align:middle line:84% You'd like to just get it down to one. 01:24:57.000 --> 01:24:58.500 align:middle line:84% AUDIENCE: It's basically saying it's 01:24:58.500 --> 01:25:01.050 align:middle line:84% going to be polynomial [INAUDIBLE] small [INAUDIBLE].. 01:25:01.050 --> 01:25:01.560 align:middle line:90% JUSTIN SOLOMON: That's right. 01:25:01.560 --> 01:25:04.080 align:middle line:84% Or it's polynomial in everything except for the things 01:25:04.080 --> 01:25:06.205 align:middle line:90% it's exponential in. 01:25:06.205 --> 01:25:09.090 align:middle line:84% And moreover, the things it's exponential in are small. 01:25:09.090 --> 01:25:10.360 align:middle line:90% And the problem says that. 01:25:10.360 --> 01:25:12.120 align:middle line:84% So I encourage you guys to take a look. 01:25:12.120 --> 01:25:14.140 align:middle line:84% Because it really does take some time to logic through it. 01:25:14.140 --> 01:25:15.557 align:middle line:84% But the setup for that problem is, 01:25:15.557 --> 01:25:18.990 align:middle line:84% I think, longer than my glacially slow board-writing 01:25:18.990 --> 01:25:20.910 align:middle line:90% can handle. 01:25:20.910 --> 01:25:24.140 align:middle line:84% But with that, we'll call it for the day. 01:25:24.140 --> 01:25:28.195 align:middle line:90%