WEBVTT 00:00:00.000 --> 00:00:06.986 [SQUEAKING] [RUSTLING] [CLICKING] 00:00:18.490 --> 00:00:19.700 JASON KU: Hi, everybody. 00:00:19.700 --> 00:00:22.870 Welcome to the last lecture of 6.006. 00:00:22.870 --> 00:00:27.410 Last lecture, we talked about summing up this class 00:00:27.410 --> 00:00:30.400 and talking about future courses in the department that 00:00:30.400 --> 00:00:33.520 use this material. 00:00:33.520 --> 00:00:36.640 Just as a pointer to some of those classes, 00:00:36.640 --> 00:00:38.680 I have a little slide here I didn't get to 00:00:38.680 --> 00:00:41.397 at the last lecture, talking about what 00:00:41.397 --> 00:00:43.480 I was talking about at the end of the last lecture 00:00:43.480 --> 00:00:46.300 about different models-- 00:00:46.300 --> 00:00:50.680 different specialized classes on different aspects of 006 00:00:50.680 --> 00:00:52.030 material-- 00:00:52.030 --> 00:00:55.690 for example, more graph stuff, different models 00:00:55.690 --> 00:00:59.230 of computation, randomness, complexity. 00:00:59.230 --> 00:01:02.050 All of these things have their own specialized classes 00:01:02.050 --> 00:01:05.860 in the department, as well as a lot of applications 00:01:05.860 --> 00:01:09.760 for this material in subjects like biology, cryptography, 00:01:09.760 --> 00:01:14.860 and in particular, for your instructors, the realm 00:01:14.860 --> 00:01:17.440 of graphics and geometry. 00:01:17.440 --> 00:01:19.390 All of your instructors this term 00:01:19.390 --> 00:01:22.990 happened to be geometers and be interested 00:01:22.990 --> 00:01:26.200 in geometry-related problems. 00:01:26.200 --> 00:01:29.440 Me in particular, I didn't start out in computer science. 00:01:29.440 --> 00:01:32.500 I started out in mechanical engineering. 00:01:32.500 --> 00:01:37.210 And the thing that was my passion coming into MIT 00:01:37.210 --> 00:01:39.370 was origami. 00:01:39.370 --> 00:01:44.560 Here's a couple of pieces that I designed-- 00:01:44.560 --> 00:01:47.320 origami pieces, one square sheet of paper without cutting. 00:01:47.320 --> 00:01:54.190 Here's a lobster, and here's a copyrighted dinosaur 00:01:54.190 --> 00:01:57.040 from a particular movie of the year that I designed it. 00:02:01.790 --> 00:02:03.530 When I was young, in high school, 00:02:03.530 --> 00:02:06.830 I started designing my own origami models. 00:02:06.830 --> 00:02:10.070 And what I didn't realize was, the procedures 00:02:10.070 --> 00:02:13.010 that I went about designing these models 00:02:13.010 --> 00:02:15.020 was actually algorithms. 00:02:15.020 --> 00:02:17.390 And I just didn't have the mathematical language 00:02:17.390 --> 00:02:20.990 to understand exactly what I was doing, 00:02:20.990 --> 00:02:24.230 but I could gain some intuition as an origami artist 00:02:24.230 --> 00:02:26.947 and design these things by using some 00:02:26.947 --> 00:02:28.280 of those algorithmic techniques. 00:02:28.280 --> 00:02:32.210 It wasn't until grad school, as a mechanical engineer, 00:02:32.210 --> 00:02:38.990 that I started talking with our other instructor here, 00:02:38.990 --> 00:02:43.100 Professor Demaine, about using algorithms and computer science 00:02:43.100 --> 00:02:48.590 to design not just origami, which we both do, 00:02:48.590 --> 00:02:53.390 but also folded structures that can be used for mechanical 00:02:53.390 --> 00:03:01.460 applications like space flight, deployable bridges in times 00:03:01.460 --> 00:03:04.160 when you can't-- 00:03:04.160 --> 00:03:07.640 you need a temporary bridge or shelter or something like that. 00:03:07.640 --> 00:03:10.280 Deployable structures where you might 00:03:10.280 --> 00:03:13.880 need to make folded structures-- transformable structures that 00:03:13.880 --> 00:03:18.290 can have different applications for different purposes-- 00:03:18.290 --> 00:03:19.670 need to reconfigure. 00:03:19.670 --> 00:03:22.880 The dream being that, we have these powerful devices 00:03:22.880 --> 00:03:26.250 in our pockets right now-- cell phones-- 00:03:26.250 --> 00:03:29.720 which are really powerful because we can reconfigure 00:03:29.720 --> 00:03:31.490 the bits in them to make software 00:03:31.490 --> 00:03:33.230 of all different kinds, right? 00:03:33.230 --> 00:03:36.800 There's an exponential number of different programs 00:03:36.800 --> 00:03:37.610 that we can write. 00:03:37.610 --> 00:03:39.590 And that's part of why you're here, 00:03:39.590 --> 00:03:41.210 is to write the next best one. 00:03:41.210 --> 00:03:42.020 Right? 00:03:42.020 --> 00:03:47.960 So that's how to make kind of a universal device 00:03:47.960 --> 00:03:49.520 at the electronic level. 00:03:49.520 --> 00:03:53.990 What if we could do that from a material standpoint? 00:03:53.990 --> 00:03:57.620 What if I could reprogram the matter in my phone so that, 00:03:57.620 --> 00:04:02.030 not only could I reprogram the app that's on your phone, 00:04:02.030 --> 00:04:06.620 but instead of having, say, the iPhone 10 or whatever that you 00:04:06.620 --> 00:04:09.050 have, and you want to go by the iPhone 11, 00:04:09.050 --> 00:04:13.940 instead, you download a software app that then reconfigures 00:04:13.940 --> 00:04:15.440 the matter in your phone-- 00:04:15.440 --> 00:04:20.779 it folds or reconfigures into the next generation iPhone. 00:04:20.779 --> 00:04:23.060 You don't have to throw away that old one. 00:04:23.060 --> 00:04:24.860 You can essentially recycle the material 00:04:24.860 --> 00:04:29.450 that you have to potentially save material, save 00:04:29.450 --> 00:04:33.000 cost, and be better for the environment, potentially. 00:04:33.000 --> 00:04:37.130 So I started moving into computer science 00:04:37.130 --> 00:04:40.160 because I found that it was a really good way 00:04:40.160 --> 00:04:42.770 to model the world and solve some really 00:04:42.770 --> 00:04:48.500 interesting problems about folding that I really enjoyed. 00:04:48.500 --> 00:04:51.860 The three of us today are going to spend 00:04:51.860 --> 00:04:54.050 some time talking a little bit about how 00:04:54.050 --> 00:04:55.880 we can use algorithms-- 00:04:55.880 --> 00:04:58.550 6.006 material and beyond-- 00:04:58.550 --> 00:05:00.260 in our own research. 00:05:00.260 --> 00:05:03.650 And we're going to start off with Professor Demaine, 00:05:03.650 --> 00:05:04.790 and then Professor Solomon. 00:05:07.532 --> 00:05:08.910 ERIK DEMAINE: Thanks. 00:05:08.910 --> 00:05:12.890 So let me just jump in here to computational origami 00:05:12.890 --> 00:05:15.590 and geometric folding algorithms, 00:05:15.590 --> 00:05:18.800 sort of a broader umbrella for folding-related things, which 00:05:18.800 --> 00:05:22.340 is encapsulated by this class, 6.849, 00:05:22.340 --> 00:05:23.630 which is happening next fall. 00:05:23.630 --> 00:05:25.940 So you should all take it. 00:05:25.940 --> 00:05:29.900 006 should be a reasonable background. 00:05:29.900 --> 00:05:33.420 And in general, we're interested in two kinds of problems. 00:05:33.420 --> 00:05:35.810 One-- the big one is origami design, 00:05:35.810 --> 00:05:37.610 or in general, folding design, where 00:05:37.610 --> 00:05:40.310 you have some specifications of what you would like to build. 00:05:40.310 --> 00:05:44.540 In this case I wanted to make a logo for 6.849. 00:05:44.540 --> 00:05:50.330 And I imagined extruding that text into third dimension. 00:05:50.330 --> 00:05:53.300 And then I wanted an algorithm to tell me 00:05:53.300 --> 00:05:54.632 how to fold that structure. 00:05:54.632 --> 00:05:56.090 And so there is an algorithm, which 00:05:56.090 --> 00:05:57.140 I'll talk about in a moment, that 00:05:57.140 --> 00:05:58.265 gives you a crease pattern. 00:05:58.265 --> 00:06:00.110 And then, currently, you fold it by hand. 00:06:00.110 --> 00:06:02.510 The dream is, we'll eventually have folding machines that 00:06:02.510 --> 00:06:05.370 do it all for us. 00:06:05.370 --> 00:06:06.770 And so that's the origami design, 00:06:06.770 --> 00:06:09.440 where you go from the target shape 00:06:09.440 --> 00:06:13.970 back to the crease pattern. 00:06:13.970 --> 00:06:15.860 The reverse direction is sort of foldability. 00:06:15.860 --> 00:06:19.010 If I gave you a structure like this and I wanted to know, 00:06:19.010 --> 00:06:20.870 does it fold? 00:06:20.870 --> 00:06:23.540 That's the problem we call foldability-- 00:06:23.540 --> 00:06:25.610 in general, class of problems. 00:06:25.610 --> 00:06:27.890 And sadly, most of those problems are NP-hard. 00:06:27.890 --> 00:06:31.340 Jason and I proved that foldability 00:06:31.340 --> 00:06:34.100 is hard for a general-- given a crease pattern like that, 00:06:34.100 --> 00:06:35.810 telling you whether folds into anything, 00:06:35.810 --> 00:06:37.150 it turns out to be NP-hard. 00:06:37.150 --> 00:06:39.270 So that's bad news. 00:06:39.270 --> 00:06:41.570 So we focus a lot on the design problem, 00:06:41.570 --> 00:06:43.380 because that actually tends to be easier. 00:06:43.380 --> 00:06:46.340 We can solve it with algorithms like that one you're seeing. 00:06:49.040 --> 00:06:52.970 A long time ago, we proved that you can fold everything. 00:06:52.970 --> 00:06:54.920 If I give you a square piece of paper 00:06:54.920 --> 00:06:58.012 and you take any polygon you want to make-- 00:06:58.012 --> 00:07:00.470 or maybe the paper's white on one side, black on the other, 00:07:00.470 --> 00:07:03.200 you want to fold some two-color pattern, like a zebra, 00:07:03.200 --> 00:07:05.840 or in general, some three-dimensional surface, 00:07:05.840 --> 00:07:08.390 like these guys, there is a way to fold it 00:07:08.390 --> 00:07:10.877 from a large enough square of paper. 00:07:10.877 --> 00:07:13.460 And it's actually really easy to prove that with an algorithm. 00:07:13.460 --> 00:07:16.790 I have the sketch of the two pages of proof 00:07:16.790 --> 00:07:19.220 that we go over in 6.849, but I'll just 00:07:19.220 --> 00:07:20.660 hand-wave a little bit. 00:07:20.660 --> 00:07:23.270 If you take a piece of paper, like my lecture notes 00:07:23.270 --> 00:07:26.570 here, the first thing you do is fold it down 00:07:26.570 --> 00:07:28.730 into a very long, narrow strip-- 00:07:28.730 --> 00:07:30.740 much longer and narrower than this one-- 00:07:30.740 --> 00:07:32.480 wasting most of the material. 00:07:32.480 --> 00:07:35.030 And then you take your strip, and you just figure out 00:07:35.030 --> 00:07:37.640 how to turn it in some general way, 00:07:37.640 --> 00:07:39.800 and then you just sort of zigzag back and forth 00:07:39.800 --> 00:07:41.130 along the surface. 00:07:41.130 --> 00:07:43.730 So it's very cool in that you can prove with an algorithm, 00:07:43.730 --> 00:07:45.677 and in a very short amount of time, 00:07:45.677 --> 00:07:47.510 to someone you can actually fold everything. 00:07:47.510 --> 00:07:48.830 Of course, it's a terrible folding, 00:07:48.830 --> 00:07:50.247 because in the very first step, we 00:07:50.247 --> 00:07:54.140 throw away all but epsilon of the material. 00:07:54.140 --> 00:07:55.640 But it's a starting point. 00:07:55.640 --> 00:07:56.870 That was back in the '90s-- 00:07:56.870 --> 00:07:59.060 late '90s-- one of the first results 00:07:59.060 --> 00:08:00.740 in computational origami. 00:08:00.740 --> 00:08:04.130 And in modern times, we look for better algorithms 00:08:04.130 --> 00:08:07.280 that are more efficient, that try to minimize the scale 00:08:07.280 --> 00:08:09.200 factor from, how big of a piece of paper 00:08:09.200 --> 00:08:13.070 do I start from to, how big of a model do I get? 00:08:13.070 --> 00:08:15.650 And one of the cool ways these days, which 00:08:15.650 --> 00:08:17.720 was invented by Tomohiro Tachi and then 00:08:17.720 --> 00:08:19.642 analyzed by the two of us-- 00:08:19.642 --> 00:08:20.600 it's called Origamizer. 00:08:20.600 --> 00:08:21.650 It's free software. 00:08:21.650 --> 00:08:25.190 You take a 3D model and you can-- 00:08:25.190 --> 00:08:27.830 it makes it into a pattern that you fold from a square. 00:08:27.830 --> 00:08:32.330 In this case, it uses 22% of the area, which is pretty good-- 00:08:32.330 --> 00:08:36.620 similar to these guys in terms of efficiency. 00:08:36.620 --> 00:08:39.380 But very, very different kind of folding 00:08:39.380 --> 00:08:42.923 than what you would get from more traditional origami 00:08:42.923 --> 00:08:44.840 design, which uses different algorithms, which 00:08:44.840 --> 00:08:45.650 I'm not going to talk about. 00:08:45.650 --> 00:08:46.520 But you should take the class. 00:08:46.520 --> 00:08:47.978 Jason gives a lecture in the class, 00:08:47.978 --> 00:08:50.940 so you can learn from him. 00:08:50.940 --> 00:08:54.560 But the vision is, we can take any sheet of material that 00:08:54.560 --> 00:08:57.530 can hold a crease, like this sheet of steel 00:08:57.530 --> 00:08:58.610 that Tomohiro is folding. 00:08:58.610 --> 00:09:02.490 It was cut by a big laser cutter at MIT. 00:09:02.490 --> 00:09:04.010 And this is him in this Data Center 00:09:04.010 --> 00:09:08.450 several years ago, folding it into a steel bunny. 00:09:08.450 --> 00:09:13.100 And so this is a totally new way to manufacture 3D objects. 00:09:13.100 --> 00:09:16.370 And you can make particularly interesting objects 00:09:16.370 --> 00:09:21.780 that either collapse flat for transportation or transform, 00:09:21.780 --> 00:09:24.260 like Jason was talking about. 00:09:24.260 --> 00:09:26.420 But I'm just giving you a flavor. 00:09:26.420 --> 00:09:30.230 I think the first paper we wrote together was on maze folding. 00:09:30.230 --> 00:09:32.960 So this is an example of folding a maze 00:09:32.960 --> 00:09:34.860 from a rectangle of paper. 00:09:34.860 --> 00:09:38.510 And you can all try this out. 00:09:38.510 --> 00:09:41.660 You just google for our Maze Folder. 00:09:41.660 --> 00:09:43.400 You can generate a random maze. 00:09:43.400 --> 00:09:46.940 And this 3D structure can be folded 00:09:46.940 --> 00:09:49.490 from this crease pattern. 00:09:49.490 --> 00:09:53.010 That's a really hard one, so maybe try something smaller. 00:09:53.010 --> 00:09:58.880 You can also write your favorite message and fold this maze-- 00:09:58.880 --> 00:10:03.058 extruded graph-- from this crease pattern. 00:10:03.058 --> 00:10:04.850 Might want to start with something smaller, 00:10:04.850 --> 00:10:07.190 but that's the general idea. 00:10:07.190 --> 00:10:09.860 And it's actually quite easy to prove this algorithmically, 00:10:09.860 --> 00:10:11.600 if you have a really good origamist 00:10:11.600 --> 00:10:13.220 like Jason on your team. 00:10:13.220 --> 00:10:17.130 What you do is design how to fold each type of vertex. 00:10:17.130 --> 00:10:19.520 This is just a graph on a grid. 00:10:19.520 --> 00:10:22.070 There are some constant number of different ways 00:10:22.070 --> 00:10:23.300 that each vertex could look. 00:10:23.300 --> 00:10:24.260 It could be degree 4. 00:10:24.260 --> 00:10:27.920 It could be degree 3, as a T. It could be degree 00:10:27.920 --> 00:10:29.630 2, either a turn or a straight. 00:10:29.630 --> 00:10:32.810 And you design little gadgets, little crease patterns, 00:10:32.810 --> 00:10:34.838 that fold into each of those little structures. 00:10:34.838 --> 00:10:37.130 And if you can do it in a way that these boundaries are 00:10:37.130 --> 00:10:39.110 compatible, then to fold the whole thing, 00:10:39.110 --> 00:10:41.360 you just sort of gluon together those crease patterns. 00:10:41.360 --> 00:10:44.930 And that's how that software works. 00:10:44.930 --> 00:10:46.850 This was particularly interesting, 00:10:46.850 --> 00:10:50.210 because you can fold an arbitrarily complicated graph-- 00:10:50.210 --> 00:10:52.640 arbitrarily complicated maze, n by n, 00:10:52.640 --> 00:10:54.055 with a constant scale factor. 00:10:54.055 --> 00:10:55.430 As long as the height that you're 00:10:55.430 --> 00:10:58.340 extruding that maze is constant, then 00:10:58.340 --> 00:11:00.950 this is one family of shapes we know how to fold really well. 00:11:00.950 --> 00:11:02.720 In general, we're trying to understand, 00:11:02.720 --> 00:11:06.410 what makes this lobster a nice shape in that it 00:11:06.410 --> 00:11:09.530 can be represented with a not-too-large piece of paper. 00:11:09.530 --> 00:11:13.960 And we don't have general answers to that problem. 00:11:13.960 --> 00:11:17.800 I think that was a whirlwind tour of computational origami. 00:11:17.800 --> 00:11:21.670 I also play a lot in algorithmic sculpture. 00:11:21.670 --> 00:11:25.540 One of the leading edges in origami and origami math 00:11:25.540 --> 00:11:28.550 is understanding how curved creases work. 00:11:28.550 --> 00:11:30.520 And one of our favorite models is 00:11:30.520 --> 00:11:33.340 this one, where you fold concentric circles alternating 00:11:33.340 --> 00:11:35.740 mountain and valley, cut a circular hole out, 00:11:35.740 --> 00:11:38.890 and it folds into this kind of Pringle shape 00:11:38.890 --> 00:11:42.820 as a nice physics equilibrium thing. 00:11:42.820 --> 00:11:46.600 And then you can turn it into fun sculptures like this. 00:11:46.600 --> 00:11:49.570 These are done with my dad, Martin Demaine, who's also here 00:11:49.570 --> 00:11:51.760 at MIT, or this guy. 00:11:51.760 --> 00:11:54.550 This paper has been printed with a pattern 00:11:54.550 --> 00:11:56.740 according to getting burned by glass. 00:11:56.740 --> 00:12:00.490 And then it gets folded and then put inside glass, also. 00:12:00.490 --> 00:12:03.340 Made here at MIT. 00:12:03.340 --> 00:12:05.710 We use sculpture to try to explore and understand 00:12:05.710 --> 00:12:07.240 intuitively how curved creases work, 00:12:07.240 --> 00:12:09.550 and then we get better and better understanding 00:12:09.550 --> 00:12:11.970 of the mathematics of even-- 00:12:11.970 --> 00:12:14.470 we don't even know whether this surface exists, whether it's 00:12:14.470 --> 00:12:17.087 possible to fold in this way, although getting 00:12:17.087 --> 00:12:17.920 close to proving it. 00:12:20.590 --> 00:12:26.380 That was sort of in the top level of this hierarchy. 00:12:26.380 --> 00:12:29.350 Computational geometry is a bigger umbrella, 00:12:29.350 --> 00:12:31.630 which is represented by another class, 6.850, 00:12:31.630 --> 00:12:33.430 that's being taught this term. 00:12:33.430 --> 00:12:35.830 And then I talked about geometric folding 00:12:35.830 --> 00:12:37.150 within that branch. 00:12:37.150 --> 00:12:39.160 Let me briefly tell you about another world 00:12:39.160 --> 00:12:43.000 of geometry-- very different in terms of model of computation. 00:12:43.000 --> 00:12:45.670 Oh, I jumped ahead a little bit. 00:12:45.670 --> 00:12:46.630 Rewind. 00:12:46.630 --> 00:12:48.740 Let me show you one more fun demo, 00:12:48.740 --> 00:12:50.920 which-- if I find my scissors. 00:12:54.580 --> 00:12:58.750 If I take a rectangle of paper, and I fold it flat 00:12:58.750 --> 00:13:03.430 and make one straight cut, what shapes can I get? 00:13:03.430 --> 00:13:05.880 It's called the folding cut problem. 00:13:05.880 --> 00:13:09.400 It's hundreds of years old. 00:13:09.400 --> 00:13:15.550 Here, for example, I get a swan. 00:13:15.550 --> 00:13:26.535 Here, I get-- one straight cut. 00:13:26.535 --> 00:13:32.070 I unfold and get angelfish. 00:13:32.070 --> 00:13:33.920 Tough audience today. 00:13:33.920 --> 00:13:34.890 I've got to keep going. 00:13:34.890 --> 00:13:36.490 You've seen all of these before. 00:13:36.490 --> 00:13:40.040 This is this one is a particularly difficult one 00:13:40.040 --> 00:13:40.825 to fold-- 00:13:40.825 --> 00:13:42.480 to only fold. 00:13:42.480 --> 00:13:45.430 And to cut, yeah. 00:13:45.430 --> 00:13:46.590 OK. 00:13:46.590 --> 00:13:47.530 That works well. 00:13:50.710 --> 00:13:56.250 This is the MIT logo. 00:13:56.250 --> 00:13:57.818 Ooh, ah. 00:13:57.818 --> 00:13:58.814 AUDIENCE: Ooh, aah. 00:13:58.814 --> 00:13:59.708 MIT, yeah! 00:13:59.708 --> 00:14:00.500 ERIK DEMAINE: Yeah. 00:14:00.500 --> 00:14:02.030 Go, MIT. 00:14:02.030 --> 00:14:03.710 All right. 00:14:03.710 --> 00:14:05.330 That's actually the first problem 00:14:05.330 --> 00:14:07.040 I worked on in computational origami. 00:14:07.040 --> 00:14:07.950 It's a lot of fun. 00:14:07.950 --> 00:14:10.460 And there's a really interesting algorithm here, also, 00:14:10.460 --> 00:14:12.260 for computing the crease pattern, 00:14:12.260 --> 00:14:14.930 how to fold your piece of paper to align-- 00:14:14.930 --> 00:14:17.987 in fact, any graph you draw on a piece of paper, 00:14:17.987 --> 00:14:20.070 you can align all of those edges and nothing else. 00:14:20.070 --> 00:14:23.730 So you cut along the line and you get exactly what you want. 00:14:23.730 --> 00:14:24.570 Cool. 00:14:24.570 --> 00:14:25.200 All right. 00:14:25.200 --> 00:14:27.730 Now, I want to talk about something completely different, 00:14:27.730 --> 00:14:29.160 which is self-assembly. 00:14:29.160 --> 00:14:33.270 A fun thing you can do with DNA, which we all have. 00:14:33.270 --> 00:14:35.640 Just pick out some cool DNA strands 00:14:35.640 --> 00:14:38.520 and design them in a clever way so they fit together 00:14:38.520 --> 00:14:42.090 to form a kind of square with dangling ends, which 00:14:42.090 --> 00:14:44.640 I'll call glues and each of those dangling ends 00:14:44.640 --> 00:14:46.170 can have a very particular pattern, 00:14:46.170 --> 00:14:49.440 and only identical or complementary patterns 00:14:49.440 --> 00:14:51.970 will attach to each other. 00:14:51.970 --> 00:14:53.670 And so you can use this to design 00:14:53.670 --> 00:14:56.640 your own self-assembling system, like biology 00:14:56.640 --> 00:15:00.100 does, but engineered, for example, to build a computer. 00:15:00.100 --> 00:15:03.660 This is an example of taking a bunch of these square tiles 00:15:03.660 --> 00:15:05.370 and building a binary counter. 00:15:05.370 --> 00:15:08.550 This thing is roughly counting in binary along the diagonal. 00:15:08.550 --> 00:15:10.390 It's a little skewed, so it's hard to see. 00:15:10.390 --> 00:15:19.170 But the general model is, you have squares-- 00:15:19.170 --> 00:15:22.770 this is sort of the computational model-- 00:15:22.770 --> 00:15:24.120 with four different glues. 00:15:24.120 --> 00:15:26.230 And you can build any square you want, 00:15:26.230 --> 00:15:29.670 but you don't have very many of these different glues, ideally. 00:15:29.670 --> 00:15:35.190 And then, if you have two tiles with complementary glues, 00:15:35.190 --> 00:15:37.530 they will want to match together. 00:15:37.530 --> 00:15:41.160 But it depends how strong this glue is, how much affinity 00:15:41.160 --> 00:15:44.532 there is for how long those DNA dangling ends are, 00:15:44.532 --> 00:15:46.240 and also, the temperature of your system. 00:15:46.240 --> 00:15:47.460 If you have really high temperature, nothing. 00:15:47.460 --> 00:15:49.150 Will stick together low temperature, 00:15:49.150 --> 00:15:53.160 things will stick together even if they're not supposed to. 00:15:53.160 --> 00:15:55.710 If you tune your system really well, 00:15:55.710 --> 00:16:00.180 you can design a system so that maybe these guys-- these glues 00:16:00.180 --> 00:16:01.690 are really strong. 00:16:01.690 --> 00:16:05.100 And so let's, I don't know, write "E" here-- 00:16:05.100 --> 00:16:06.300 Erik. 00:16:06.300 --> 00:16:09.280 And so these tiles will always glue together, 00:16:09.280 --> 00:16:11.880 but only when all three of these are glued together 00:16:11.880 --> 00:16:12.900 can this tile-- 00:16:12.900 --> 00:16:17.640 which has C complement and F complement. 00:16:17.640 --> 00:16:20.250 Then it will, if you set the temperatures just right, 00:16:20.250 --> 00:16:22.620 only because both of these edges match will 00:16:22.620 --> 00:16:24.000 this dial be able to come in. 00:16:24.000 --> 00:16:27.300 And that's the basis for building that binary counter. 00:16:27.300 --> 00:16:29.730 This is a very different model of computation 00:16:29.730 --> 00:16:31.530 from what we're used to in this class, 00:16:31.530 --> 00:16:34.260 where you think of instructions, and they run one at a time. 00:16:34.260 --> 00:16:37.440 Here the, model of computation is geometric. 00:16:37.440 --> 00:16:40.230 It's these squares that are just floating around and gluing 00:16:40.230 --> 00:16:40.750 together. 00:16:40.750 --> 00:16:42.750 And so your program, at any moment, 00:16:42.750 --> 00:16:46.273 is some conglomerate of squares. 00:16:46.273 --> 00:16:47.940 I just wanted to mention it because it's 00:16:47.940 --> 00:16:48.883 a really fun model. 00:16:48.883 --> 00:16:50.550 You can prove cool things in this model, 00:16:50.550 --> 00:16:55.290 like how to build any shape by a sequence of pores 00:16:55.290 --> 00:16:58.900 mixing between tiles that you can execute in parallel. 00:16:58.900 --> 00:17:01.200 And so it only takes log and time 00:17:01.200 --> 00:17:04.500 of parallel steps, a linear number of different mix 00:17:04.500 --> 00:17:06.780 operations, to make an arbitrary shape-- 00:17:06.780 --> 00:17:11.550 even using a constant number of different glues, which is cool, 00:17:11.550 --> 00:17:13.990 and maybe practical. 00:17:13.990 --> 00:17:15.990 You can also use it to build a replicator, where 00:17:15.990 --> 00:17:18.780 you're given an object like this that you 00:17:18.780 --> 00:17:20.503 don't know the shape of-- 00:17:20.503 --> 00:17:22.170 like, we don't know whether this exists, 00:17:22.170 --> 00:17:24.690 and we can't model it mathematically very well, 00:17:24.690 --> 00:17:27.060 and you stick it in a vat, and all of these tiles 00:17:27.060 --> 00:17:29.100 would attach and basically build a mold, 00:17:29.100 --> 00:17:32.070 and then start photocopying, in 3D, that mold. 00:17:32.070 --> 00:17:35.790 And you can build that with a system with only two steps, 00:17:35.790 --> 00:17:38.940 I believe, and a constant number of tile types. 00:17:38.940 --> 00:17:42.120 And it does all of that, in this model, in constant time. 00:17:42.120 --> 00:17:44.200 In reality, you would have to feed this machine 00:17:44.200 --> 00:17:46.560 and wait for it to print out all of these things, 00:17:46.560 --> 00:17:50.070 and these experiments take hours, if not days, to run. 00:17:50.070 --> 00:17:51.443 But in theory, it's really cool. 00:17:51.443 --> 00:17:52.860 And you get some really fun models 00:17:52.860 --> 00:17:54.310 and very general results. 00:17:54.310 --> 00:17:57.120 You can also use it to build a miniaturizer or a magnifier 00:17:57.120 --> 00:17:58.820 and other fun stuff. 00:18:01.670 --> 00:18:04.070 That was a brief tour of computational geometry. 00:18:04.070 --> 00:18:08.030 I work mostly in four different areas of algorithms-- geometry, 00:18:08.030 --> 00:18:09.890 data structures, graph algorithms, and what 00:18:09.890 --> 00:18:11.810 I call recreational algorithms. 00:18:11.810 --> 00:18:14.200 I think I made up that term. 00:18:14.200 --> 00:18:17.100 And let's go into data structures, 00:18:17.100 --> 00:18:20.720 which is represented by this class, 6.851. 00:18:20.720 --> 00:18:24.270 All of the classes I mentioned have online video lectures, 00:18:24.270 --> 00:18:28.100 especially for those watching at home on OpenCourseWare. 00:18:28.100 --> 00:18:30.830 Most of these classes are on OpenCourseWare, and if not, 00:18:30.830 --> 00:18:33.530 they're on my webpage. 00:18:33.530 --> 00:18:36.890 6.851, Advanced Data Structures, is an extension of the sorts 00:18:36.890 --> 00:18:38.990 of data structures you've seen here, 00:18:38.990 --> 00:18:42.710 in 006 and the ones you will see in 6.046. 00:18:42.710 --> 00:18:44.540 I thought I would give you a flavor 00:18:44.540 --> 00:18:54.950 of one such result, which is a problem we've 00:18:54.950 --> 00:19:00.260 seen in this class done better. 00:19:00.260 --> 00:19:03.740 Suppose you want to store a dynamic ordered set. 00:19:07.490 --> 00:19:10.040 This is the set interface. 00:19:10.040 --> 00:19:17.150 Dynamic in the sense that I have insert and delete, 00:19:17.150 --> 00:19:20.450 and ordered in the sense that I want to support find-next 00:19:20.450 --> 00:19:21.560 and find-previous. 00:19:27.290 --> 00:19:30.080 Exactly which subset of the set interface 00:19:30.080 --> 00:19:33.080 you choose influences what data structure you've seen. 00:19:33.080 --> 00:19:36.440 We've seen, for dynamic sets, you want to use hashing. 00:19:36.440 --> 00:19:37.910 If you don't care about find-next, 00:19:37.910 --> 00:19:40.070 if you just care about find, then hashing 00:19:40.070 --> 00:19:41.900 is great-- constant expected. 00:19:41.900 --> 00:19:44.020 You can prove stronger things about hashing. 00:19:44.020 --> 00:19:46.370 And we do in that class. 00:19:46.370 --> 00:19:49.610 But if you want dynamic and ordered, 00:19:49.610 --> 00:19:52.070 you cannot do constant time per operation. 00:19:52.070 --> 00:19:55.910 You can prove that, which is cool. 00:19:55.910 --> 00:19:58.640 What data structure have we seen that solves this problem pretty 00:19:58.640 --> 00:19:59.780 well? 00:19:59.780 --> 00:20:03.710 Set AVL trees, which solve everything in log n. 00:20:03.710 --> 00:20:06.980 So log n is one competitor. 00:20:13.290 --> 00:20:14.470 Yeah. 00:20:14.470 --> 00:20:20.730 I'm interested in the word RAM model, 00:20:20.730 --> 00:20:22.970 which is the only model we've seen in this class. 00:20:22.970 --> 00:20:25.550 This happens to work in a stronger model. 00:20:25.550 --> 00:20:32.247 And we can do better than log n in the following-- 00:20:32.247 --> 00:20:34.080 it will take me a while before I get better, 00:20:34.080 --> 00:20:36.530 but here's, at least, a different bound we can get-- 00:20:36.530 --> 00:20:39.590 log w. 00:20:39.590 --> 00:20:45.650 This is via a structure called van Emde Boas, who is a person. 00:20:45.650 --> 00:20:47.240 AVL is two people. 00:20:47.240 --> 00:20:50.060 van Emde Boas, I've actually met. 00:20:50.060 --> 00:20:52.942 Log w-- remember, w is our word size. 00:20:52.942 --> 00:20:54.650 So this is a bit of a weird running time. 00:20:54.650 --> 00:20:58.370 It's great if w is log n, then this is log log n. 00:20:58.370 --> 00:21:01.903 And we know w is at least log n, but it could be bigger. 00:21:01.903 --> 00:21:04.070 We don't really have a sense of how big w could get. 00:21:04.070 --> 00:21:05.150 Maybe it's even n. 00:21:05.150 --> 00:21:07.280 Maybe it's big-- and then these are the same. 00:21:07.280 --> 00:21:10.470 Maybe it's bigger than n, and then this is maybe worse. 00:21:10.470 --> 00:21:13.400 But for most ws, this is actually pretty good-- 00:21:13.400 --> 00:21:14.945 and indeed, optimal. 00:21:17.840 --> 00:21:20.690 But it's not strictly better, in any sense, yet. 00:21:20.690 --> 00:21:24.170 On the other hand, there's another data structure which 00:21:24.170 --> 00:21:27.830 runs in log n divided by log w. 00:21:27.830 --> 00:21:30.320 This is called fusion trees. 00:21:30.320 --> 00:21:31.910 This was invented around the time 00:21:31.910 --> 00:21:33.600 that cold fusion was in the news, 00:21:33.600 --> 00:21:37.515 and so they wanted data structures to represent. 00:21:40.190 --> 00:21:42.950 We can achieve this bound or we can achieve this bound. 00:21:42.950 --> 00:21:46.430 And this bound is good is if w is large. 00:21:46.430 --> 00:21:49.250 This band as good if w is small. 00:21:49.250 --> 00:21:53.480 You can always take the min of the two, whatever is better. 00:21:53.480 --> 00:22:05.030 And in particular, the min of those two things is at most-- 00:22:05.030 --> 00:22:09.980 I think it's square root log n over log log n. 00:22:09.980 --> 00:22:13.850 If you want to bound just in terms of n, 00:22:13.850 --> 00:22:16.880 then the crossover point between these two is this place. 00:22:16.880 --> 00:22:18.380 And so you're always, at most, this, 00:22:18.380 --> 00:22:21.320 which is quite a bit better than the log n of AVL. 00:22:21.320 --> 00:22:22.695 We've got a square root and we've 00:22:22.695 --> 00:22:25.460 got a slight thing in the denominator. 00:22:25.460 --> 00:22:26.318 Pretty tiny. 00:22:26.318 --> 00:22:27.860 But the big thing is the square root. 00:22:27.860 --> 00:22:29.000 And that's kind of cool. 00:22:29.000 --> 00:22:31.010 And it turns out, that's pretty much optimal. 00:22:31.010 --> 00:22:33.020 In terms of an n bound, this is optimal. 00:22:33.020 --> 00:22:35.210 The min of these two, in general, 00:22:35.210 --> 00:22:38.930 is roughly optimal up to log log terms. 00:22:38.930 --> 00:22:41.900 For fun, I threw up the actual formula 00:22:41.900 --> 00:22:45.080 for the right-bound, which is tight 00:22:45.080 --> 00:22:47.450 up to constant factors of matching upper and lower 00:22:47.450 --> 00:22:49.250 bounds, which we talk about. 00:22:49.250 --> 00:22:52.560 It's min of three things-- 00:22:52.560 --> 00:22:56.780 four things, including log of w over a divided by log of log 00:22:56.780 --> 00:22:59.800 w over a log of log n over a. 00:22:59.800 --> 00:23:01.700 That's the last term that I just read. 00:23:01.700 --> 00:23:03.380 This was messy. 00:23:03.380 --> 00:23:05.210 Surprisingly, that is the right answer 00:23:05.210 --> 00:23:07.102 for this very particular problem-- 00:23:07.102 --> 00:23:08.060 a very natural problem. 00:23:08.060 --> 00:23:09.590 AUDIENCE: What is a? 00:23:09.590 --> 00:23:12.600 ERIK DEMAINE: A is the log of the space you're using. 00:23:12.600 --> 00:23:14.960 So it's the address size. 00:23:14.960 --> 00:23:17.000 Good question. 00:23:17.000 --> 00:23:18.700 If you throw it-- so it depends. 00:23:18.700 --> 00:23:21.740 If you have a polynomial space data structure, then basically, 00:23:21.740 --> 00:23:23.250 these are optimal. 00:23:23.250 --> 00:23:26.600 And this is generalizing to beyond that. 00:23:26.600 --> 00:23:30.210 Maybe you have a little bit more than polynomial space. 00:23:30.210 --> 00:23:31.560 Cool. 00:23:31.560 --> 00:23:33.720 So that's data structures. 00:23:33.720 --> 00:23:39.150 I'm going to jump ahead to graph algorithms, which, 00:23:39.150 --> 00:23:41.670 if you want to take this class, I recommend a time travel 00:23:41.670 --> 00:23:42.270 device. 00:23:42.270 --> 00:23:44.400 Go back to fall 2011. 00:23:44.400 --> 00:23:45.780 It may never get taught again. 00:23:45.780 --> 00:23:48.330 But it has video, so you can watch-- 00:23:48.330 --> 00:23:50.042 instead of time traveling, if you 00:23:50.042 --> 00:23:51.750 don't want to watch it live, you can just 00:23:51.750 --> 00:23:53.280 watch the recorded version. 00:23:53.280 --> 00:23:55.980 It was taught by a bunch of postdocs that were here, 00:23:55.980 --> 00:23:59.100 and a bit myself. 00:23:59.100 --> 00:24:03.180 What I like to do with graphs is the world of planar graphs, 00:24:03.180 --> 00:24:04.875 or near-planar graphs. 00:24:08.538 --> 00:24:10.080 We've talked a lot about, this class, 00:24:10.080 --> 00:24:12.218 algorithms that work for arbitrary graphs. 00:24:12.218 --> 00:24:14.010 And the algorithms we've seen in this class 00:24:14.010 --> 00:24:16.740 are pretty much the best we know for a lot of problems 00:24:16.740 --> 00:24:18.948 for arbitrary graphs. 00:24:18.948 --> 00:24:20.490 But if your graph has some structure, 00:24:20.490 --> 00:24:22.590 like it's a road network and there aren't too 00:24:22.590 --> 00:24:26.310 many overpasses, you can usually draw these graphs in the plane 00:24:26.310 --> 00:24:27.240 without crossings. 00:24:27.240 --> 00:24:28.590 That's the meaning of planar. 00:24:28.590 --> 00:24:29.550 Maybe not exactly. 00:24:29.550 --> 00:24:30.990 Maybe just a few crossings. 00:24:30.990 --> 00:24:33.452 There's a generalization of this, which I won't get into. 00:24:33.452 --> 00:24:35.160 But let's just think about planar graphs. 00:24:35.160 --> 00:24:36.743 Planar graphs have some nice features, 00:24:36.743 --> 00:24:39.898 like they always have a linear number of edges. 00:24:39.898 --> 00:24:40.815 They're always sparse. 00:24:43.510 --> 00:24:46.380 So you can immediately plug that into our existing bounds. 00:24:46.380 --> 00:24:53.100 But even so, Dijkstra, in such a graph, would take v log v time. 00:24:53.100 --> 00:24:56.520 For planar graphs, you can do the equivalent of Dijkstra, 00:24:56.520 --> 00:24:58.910 meaning, I can compute single-source shortest paths 00:24:58.910 --> 00:25:01.740 with negative edge weights in linear time. 00:25:07.260 --> 00:25:09.820 No log. 00:25:09.820 --> 00:25:12.310 Not that impressive, but remove a log. 00:25:12.310 --> 00:25:16.510 More impressive is, we can do the equivalent of Bellman-Ford, 00:25:16.510 --> 00:25:18.760 which is a single-source shortest paths with arbitrary 00:25:18.760 --> 00:25:25.870 edge weights in a planar graph in some time-- 00:25:25.870 --> 00:25:26.890 almost linear time. 00:25:29.770 --> 00:25:35.200 The log squared v over log log v. So 00:25:35.200 --> 00:25:37.270 there's a couple of factors here-- 00:25:37.270 --> 00:25:39.670 but for almost linear time, whereas Bellman-Ford 00:25:39.670 --> 00:25:40.940 would take v squared time. 00:25:40.940 --> 00:25:43.210 So this is a huge improvement over what 00:25:43.210 --> 00:25:44.320 we've seen in the class. 00:25:44.320 --> 00:25:45.670 These are quite complicated algorithms, 00:25:45.670 --> 00:25:47.087 but they're covered in that class, 00:25:47.087 --> 00:25:49.240 if you're interested in them. 00:25:49.240 --> 00:25:53.410 Then the area I work in a lot is approximation algorithms 00:25:53.410 --> 00:25:56.830 for planar graphs. 00:25:56.830 --> 00:26:01.450 And let me just give you a fun flavor using something we know, 00:26:01.450 --> 00:26:05.655 which is breadth-first search. 00:26:05.655 --> 00:26:07.030 Breath-first search you can think 00:26:07.030 --> 00:26:13.380 of as building sort of rings around a single root node. 00:26:13.380 --> 00:26:15.150 And there's this general approach-- 00:26:15.150 --> 00:26:17.620 this was introduced by Baker in 1994, 00:26:17.620 --> 00:26:19.890 we've used for lots of different problems. 00:26:19.890 --> 00:26:23.350 We want to solve some NP-hard problem on a graph. 00:26:23.350 --> 00:26:26.760 So just run breadth-first search from an arbitrary vertex 00:26:26.760 --> 00:26:29.162 and decompose your graph into these layers. 00:26:29.162 --> 00:26:30.120 You could number them-- 00:26:30.120 --> 00:26:32.550 0, 1, 2, 3. 00:26:32.550 --> 00:26:35.370 These are levels. 00:26:35.370 --> 00:26:38.760 And let's just, like, delete some of those layers. 00:26:38.760 --> 00:26:41.680 Let's say, let's delete every fourth layer. 00:26:41.680 --> 00:26:43.068 So maybe I delete this one. 00:26:43.068 --> 00:26:44.860 I delete all of the vertices in that layer. 00:26:44.860 --> 00:26:46.693 And then I delete all of the things in layer 00:26:46.693 --> 00:26:50.670 8, and layer 12, and so on. 00:26:50.670 --> 00:26:54.180 Guessing-- I don't know which one to start with, but from-- 00:26:54.180 --> 00:26:55.260 I'll just try them all. 00:26:55.260 --> 00:26:58.380 And then I delete every fourth layer after that. 00:26:58.380 --> 00:27:02.520 So I've deleted, on average, about a quarter of the graph. 00:27:02.520 --> 00:27:06.660 And it turns out, for a lot of problems that you care about, 00:27:06.660 --> 00:27:09.990 like choosing where to place fire stations in this graph 00:27:09.990 --> 00:27:12.960 to minimize travel time for if there's 00:27:12.960 --> 00:27:14.672 a fire somewhere in the graph-- 00:27:14.672 --> 00:27:15.630 this happens, you know? 00:27:15.630 --> 00:27:17.610 Fires and graphs. 00:27:17.610 --> 00:27:21.120 Then this will only hurt your solution by, like, 00:27:21.120 --> 00:27:26.610 a factor of 1 plus a quarter. 00:27:26.610 --> 00:27:29.250 So you will get a solution that's 00:27:29.250 --> 00:27:35.350 within 25% of the optimal, for a lot of problems. 00:27:35.350 --> 00:27:38.470 And that works for any value 4. 00:27:38.470 --> 00:27:40.600 So I could do it for 10, and then I 00:27:40.600 --> 00:27:43.960 would get within 10% of the optimal solution. 00:27:43.960 --> 00:27:46.390 OK, but how do I actually solve the problem once I 00:27:46.390 --> 00:27:48.040 delete every fourth layer? 00:27:48.040 --> 00:27:50.890 Well, then your graph has this extra special structure, 00:27:50.890 --> 00:27:53.180 which is a constant number of layers, let's say. 00:27:53.180 --> 00:27:54.610 A constant number of breadth-first search layers. 00:27:54.610 --> 00:27:56.260 If you just look at this portion, 00:27:56.260 --> 00:27:58.760 this connected component, or this connected component 00:27:58.760 --> 00:28:00.430 in here, you can-- 00:28:00.430 --> 00:28:03.790 your graph is almost like a cycle. 00:28:03.790 --> 00:28:06.100 It's like four cycles stacked up together 00:28:06.100 --> 00:28:07.563 with some connections between them. 00:28:07.563 --> 00:28:08.980 And it turns out, that's something 00:28:08.980 --> 00:28:12.370 you can solve with very fancy dynamic programming, 00:28:12.370 --> 00:28:14.800 like the stuff we've seen in this class, which 00:28:14.800 --> 00:28:17.125 focuses on just a single path or a single cycle. 00:28:17.125 --> 00:28:19.000 If you just have a constant number of cycles, 00:28:19.000 --> 00:28:22.600 with more work, you can still do everything in polynomial time. 00:28:22.600 --> 00:28:26.150 This is a very general approach for getting arbitrarily 00:28:26.150 --> 00:28:27.400 good approximation algorithms. 00:28:27.400 --> 00:28:31.930 We call these 1 plus epsilon approximation for any epsilon. 00:28:31.930 --> 00:28:34.210 But the larger the epsilon, the more time you take. 00:28:34.210 --> 00:28:39.610 It's something like 2 to the order 1 over epsilon times 00:28:39.610 --> 00:28:41.470 polynomial n. 00:28:41.470 --> 00:28:42.970 So as long as epsilon is constant, 00:28:42.970 --> 00:28:44.773 this is polynomial time. 00:28:44.773 --> 00:28:45.690 This is called a PTAS. 00:28:49.090 --> 00:28:51.310 Anyway, that was graph algorithms. 00:28:51.310 --> 00:28:55.300 Last topic is recreational algorithms, which is maybe 00:28:55.300 --> 00:28:56.830 best encompassed by this class. 00:28:56.830 --> 00:28:58.840 6.892 is its latest name. 00:28:58.840 --> 00:29:00.940 It changes names every once in a while. 00:29:00.940 --> 00:29:04.180 And I mentioned it in the hardness complexity lecture, 00:29:04.180 --> 00:29:06.460 because this class is all about hardness proofs, 00:29:06.460 --> 00:29:08.410 analyzing fun games and puzzles. 00:29:08.410 --> 00:29:12.160 We saw the Tetris NP-hardness in that lecture. 00:29:12.160 --> 00:29:15.490 But you can also prove Super Mario Brothers is hard, 00:29:15.490 --> 00:29:18.070 or Portal is hard, or Mario Kart is hard, 00:29:18.070 --> 00:29:21.340 or The Witness, a modern video game, is hard. 00:29:21.340 --> 00:29:24.070 Or, one of our latest results is that Recurse-- 00:29:24.070 --> 00:29:26.740 that game in the top right-- is undecidable. 00:29:26.740 --> 00:29:32.740 There's no algorithm to play that game perfectly. 00:29:32.740 --> 00:29:34.790 And you can even download the level-- 00:29:34.790 --> 00:29:40.070 an example of the level and play it, if you dare. 00:29:40.070 --> 00:29:41.800 So that's a lot of-- 00:29:41.800 --> 00:29:44.950 we have a lot of fun in that world of hardness 00:29:44.950 --> 00:29:47.310 of different games and puzzles. 00:29:47.310 --> 00:29:50.330 Where do I want to go next? 00:29:50.330 --> 00:29:50.830 OK. 00:29:50.830 --> 00:29:52.420 Next topic is balloon twisting. 00:29:52.420 --> 00:29:53.620 Totally different. 00:29:53.620 --> 00:29:56.350 This is recreational, but not about hardness. 00:29:56.350 --> 00:30:01.270 This is an octahedron twisted from one balloon. 00:30:01.270 --> 00:30:03.917 I made another one on a stick. 00:30:03.917 --> 00:30:05.500 Each of these is made for one balloon. 00:30:05.500 --> 00:30:08.860 What graphs can you make for one balloon? 00:30:08.860 --> 00:30:10.423 Well, you should read our paper. 00:30:10.423 --> 00:30:12.340 And you can characterize how many balloons you 00:30:12.340 --> 00:30:15.220 need to make each polyhedron. 00:30:15.220 --> 00:30:21.170 And some of these problems are NP-hard, and it's a lot of fun. 00:30:21.170 --> 00:30:21.670 Cool. 00:30:21.670 --> 00:30:23.980 I think that's the end of the slides. 00:30:23.980 --> 00:30:25.690 The last thing I wanted to show you 00:30:25.690 --> 00:30:32.890 is a problem, a puzzle/magic trick-- 00:30:32.890 --> 00:30:34.480 it comes from the puzzle world-- 00:30:34.480 --> 00:30:35.990 called the picture hanging problem. 00:30:35.990 --> 00:30:37.750 So imagine you have a picture. 00:30:37.750 --> 00:30:39.230 You want to hang it on a wall. 00:30:39.230 --> 00:30:40.960 So you invested in some nice rope, 00:30:40.960 --> 00:30:44.140 and you hang it on a nail. 00:30:44.140 --> 00:30:47.380 If the nail falls out, the picture falls, and you're sad. 00:30:47.380 --> 00:30:50.590 So you invest in two nails, like I have here, 00:30:50.590 --> 00:30:53.500 and maybe you hang your picture on both those nails. 00:30:53.500 --> 00:30:55.870 Now, if one of the nails falls out, 00:30:55.870 --> 00:30:58.570 you still have a crookedly hung picture. 00:30:58.570 --> 00:31:01.540 If the other nail falls out, OK, it's gone. 00:31:01.540 --> 00:31:04.480 I want to hang a picture on two nails 00:31:04.480 --> 00:31:08.140 such that, if I remove either nail, the picture falls. 00:31:08.140 --> 00:31:11.070 So, Jason, pick a nail, left or right. 00:31:11.070 --> 00:31:13.010 Left, we remove. 00:31:13.010 --> 00:31:14.780 Make sure this doesn't fall off-- 00:31:14.780 --> 00:31:16.430 and, boom, the picture falls. 00:31:16.430 --> 00:31:17.422 Same wrapping. 00:31:17.422 --> 00:31:19.130 You can check-- you can rewind the video, 00:31:19.130 --> 00:31:20.450 make sure I did the same wrapping. 00:31:20.450 --> 00:31:21.680 JASON KU: And take out the right. 00:31:21.680 --> 00:31:23.430 ERIK DEMAINE: Then take out the right one. 00:31:23.430 --> 00:31:24.650 Good choice. 00:31:24.650 --> 00:31:26.600 Then, also, the picture falls. 00:31:29.150 --> 00:31:31.500 This is a classic puzzle, but you can generalize it. 00:31:31.500 --> 00:31:36.250 So let me do it for three nails, which is all I have here. 00:31:36.250 --> 00:31:39.110 This nail is sagging a little bit. 00:31:39.110 --> 00:31:42.430 y, x-- y inverse, x inverse. 00:31:42.430 --> 00:31:43.940 I think that's right. 00:31:43.940 --> 00:31:46.400 So this is one way to hang a picture on three nails 00:31:46.400 --> 00:31:49.610 such that, if I remove any of the nails, the picture falls. 00:31:49.610 --> 00:31:53.420 Justin, 1, 2, or 3? 00:31:53.420 --> 00:31:54.290 2. 00:31:54.290 --> 00:31:55.880 OK. 00:31:55.880 --> 00:31:57.440 Yeah, I want to get out of the way 00:31:57.440 --> 00:32:00.140 and make sure I don't go over the edge here. 00:32:04.380 --> 00:32:05.400 Yeah. 00:32:05.400 --> 00:32:07.780 It's a lot easier to make this one work. 00:32:07.780 --> 00:32:11.220 But you can see, boom, picture falls there. 00:32:11.220 --> 00:32:13.800 And of course, imagine infinite gravity. 00:32:13.800 --> 00:32:14.930 And the picture falls. 00:32:14.930 --> 00:32:16.710 Ta-da! 00:32:16.710 --> 00:32:19.980 You can generalize this to do essentially any-- 00:32:19.980 --> 00:32:23.160 what's called a monotone Boolean function-- on any set of nails. 00:32:23.160 --> 00:32:25.410 I mean, you can make any subset of the nails 00:32:25.410 --> 00:32:27.728 cause the picture to fall and any collection of subsets 00:32:27.728 --> 00:32:28.770 of nails to make it fall. 00:32:28.770 --> 00:32:29.880 Of course, if you remove more nails, 00:32:29.880 --> 00:32:31.200 it's still going to fall. 00:32:31.200 --> 00:32:33.030 That's the monotone sense. 00:32:33.030 --> 00:32:36.458 But otherwise, you can do an arbitrary pattern, 00:32:36.458 --> 00:32:37.000 which is fun. 00:32:37.000 --> 00:32:39.120 That's actually a result with Ron Rivest 00:32:39.120 --> 00:32:43.000 and a bunch of other people. 00:32:43.000 --> 00:32:46.370 I think I'm approximately on time. 00:32:46.370 --> 00:32:48.490 So that was a quick tour. 00:32:48.490 --> 00:32:52.030 And there are obviously various classes here you can take. 00:32:52.030 --> 00:32:55.390 6.892, the hardness class, was just offered last semester, 00:32:55.390 --> 00:32:56.890 so it probably won't be for a while. 00:32:56.890 --> 00:32:58.390 But all of these classes are online. 00:32:58.390 --> 00:33:01.270 Watch the videos, feel free to ask me questions. 00:33:01.270 --> 00:33:03.100 And now we have Justin. 00:33:03.100 --> 00:33:05.665 I left you space here for your outline. 00:33:08.390 --> 00:33:11.907 You don't have to, but I'll put your name. 00:33:11.907 --> 00:33:12.990 JUSTIN SOLOMON: Thank you. 00:33:18.170 --> 00:33:20.308 JASON KU: So Justin is also a geometer. 00:33:20.308 --> 00:33:22.850 ERIK DEMAINE: Yeah, we've got a lot of geometry people in 006 00:33:22.850 --> 00:33:24.500 this semester. 00:33:24.500 --> 00:33:25.600 JUSTIN SOLOMON: Thank you. 00:33:25.600 --> 00:33:27.580 OK. 00:33:27.580 --> 00:33:30.940 I can't help but share that, on our instructor chat, 00:33:30.940 --> 00:33:33.098 Erik was texting that he was going to be-- 00:33:33.098 --> 00:33:35.140 he was somehow nervous that the applied guy would 00:33:35.140 --> 00:33:36.910 have all of the cool stuff to show off, 00:33:36.910 --> 00:33:39.682 and now I feel totally boring. 00:33:39.682 --> 00:33:43.090 [LAUGHING] Right. 00:33:43.090 --> 00:33:44.200 Yeah. 00:33:44.200 --> 00:33:47.950 We have three different geometry instructors in this class. 00:33:47.950 --> 00:33:51.040 In this class, I think we have many different flavors 00:33:51.040 --> 00:33:52.810 of geometry that are kind of represented 00:33:52.810 --> 00:33:54.850 in this room here, from mechanical engineering, 00:33:54.850 --> 00:33:57.460 to theory plus lots of other cool stuff, 00:33:57.460 --> 00:34:00.460 to whatever it is that I do. 00:34:00.460 --> 00:34:03.730 I'm a professor, also, in CSAIL, and lead a group 00:34:03.730 --> 00:34:07.390 that studies slightly more applied geometry problems, 00:34:07.390 --> 00:34:11.350 in some sense, and in CSAIL, we kind of cross 00:34:11.350 --> 00:34:15.219 a lot of boundaries-- actually, closer to the math department 00:34:15.219 --> 00:34:17.900 than to the theory group and computer science, 00:34:17.900 --> 00:34:20.500 which I would argue is largely a historical artifact rather 00:34:20.500 --> 00:34:25.719 than anything interesting about computer science or math. 00:34:25.719 --> 00:34:29.170 Continuing in our whirlwind tour of interesting geometry classes 00:34:29.170 --> 00:34:33.227 here at MIT, I have some more fun things to add to the list. 00:34:33.227 --> 00:34:35.560 And we'll introduce some of the ideas in the next couple 00:34:35.560 --> 00:34:37.520 of slides here. 00:34:37.520 --> 00:34:41.380 So normally, every fall, I teach 6.837, 00:34:41.380 --> 00:34:43.630 which is the introduction to computer graphics course. 00:34:43.630 --> 00:34:47.110 In fact, my background was working in an animation studio 00:34:47.110 --> 00:34:50.889 for a little bit of time, and got one movie credit out of it 00:34:50.889 --> 00:34:53.050 until they changed the standards for movie credits, 00:34:53.050 --> 00:34:55.489 and then that stopped happening. 00:34:55.489 --> 00:34:57.700 But in any event, if you watch-- what's that movie-- 00:34:57.700 --> 00:34:58.860 Up, with the old man. 00:34:58.860 --> 00:35:00.610 If you hit pause at just the right moment, 00:35:00.610 --> 00:35:02.830 you can find me right above the list of babies that 00:35:02.830 --> 00:35:05.800 were born during production. 00:35:05.800 --> 00:35:07.150 But in any event-- 00:35:07.150 --> 00:35:08.650 although computer graphics might not 00:35:08.650 --> 00:35:10.192 sound like an algorithmic discipline, 00:35:10.192 --> 00:35:12.963 I'll try to convince you guys that, in some sense, 00:35:12.963 --> 00:35:15.130 you could take just about anybody in our department, 00:35:15.130 --> 00:35:17.710 have them teach 6.006, and give a similar talk that, 00:35:17.710 --> 00:35:20.200 like, the material that you've encountered in this course 00:35:20.200 --> 00:35:23.150 is going to be relevant to your life. 00:35:23.150 --> 00:35:25.810 The other course that I teach that might be of interest-- 00:35:25.810 --> 00:35:28.660 and actually, is a little more theoretically flavored-- 00:35:28.660 --> 00:35:31.120 that I teach is 6.838. 00:35:31.120 --> 00:35:34.150 So since Erik so kindly put my name on the board here, 00:35:34.150 --> 00:35:36.730 I guess I can draw The So the main object 00:35:36.730 --> 00:35:39.760 of interest in 6.838 is a particular thing 00:35:39.760 --> 00:35:41.410 called the simplicial complex. 00:35:47.600 --> 00:35:50.330 Usually, in 6.006, we spend a lot 00:35:50.330 --> 00:35:52.100 of time thinking about graphs. 00:35:52.100 --> 00:35:53.930 Let me draw you a graph. 00:35:53.930 --> 00:35:57.890 So I'm going to take a square and subdivide it. 00:35:57.890 --> 00:36:04.090 And now, let's say I put edges diagonally like that. 00:36:04.090 --> 00:36:08.390 Now, in 6.006, this thing is just a bunch 00:36:08.390 --> 00:36:09.890 of nodes connected by edges. 00:36:09.890 --> 00:36:12.650 In fact, if I took this edge and I moved it down or something, 00:36:12.650 --> 00:36:14.300 it would be the same graph. 00:36:14.300 --> 00:36:17.420 But of course, in a lot of computer graphics applications, 00:36:17.420 --> 00:36:20.420 this thing also looks an awful lot like a square. 00:36:20.420 --> 00:36:22.890 And the reason is that, of course, 00:36:22.890 --> 00:36:25.800 the graph here contains triangles inside of it. 00:36:25.800 --> 00:36:29.720 And so for instance, maybe I think of my graph 00:36:29.720 --> 00:36:32.030 as a collection of vertices, a collection of edges. 00:36:32.030 --> 00:36:33.990 This is the sort of notation we've seen before. 00:36:33.990 --> 00:36:38.070 And then I add a third thing to my description, 00:36:38.070 --> 00:36:39.440 which is a set of triplets. 00:36:39.440 --> 00:36:41.565 That's a set of triangles here. 00:36:41.565 --> 00:36:43.190 And we can take a lot of the algorithms 00:36:43.190 --> 00:36:44.580 that we've talked about in this class 00:36:44.580 --> 00:36:45.705 and extend it to this case. 00:36:45.705 --> 00:36:50.510 For example, here's a deceptively annoying one. 00:36:50.510 --> 00:36:52.880 Let's say that I want the shortest path between two 00:36:52.880 --> 00:36:54.710 vertices of my graph. 00:36:54.710 --> 00:36:57.890 We certainly have learned Dijkstra's algorithm. 00:36:57.890 --> 00:36:59.430 That's one technique to do that. 00:36:59.430 --> 00:37:02.120 And indeed, common practice in computer graphics, 00:37:02.120 --> 00:37:04.760 which is shameful, is on your triangle mesh, 00:37:04.760 --> 00:37:08.090 if you want the shortest path between two vertices, run 00:37:08.090 --> 00:37:10.792 Dijkstra's algorithm on the edges. 00:37:10.792 --> 00:37:12.500 And let's see if that works really quick. 00:37:12.500 --> 00:37:14.662 Let's say that I want the shortest path between-- 00:37:14.662 --> 00:37:17.120 and, by the way, I'm going to assume the length of my edges 00:37:17.120 --> 00:37:19.328 are the lengths as I've drawn them on the board here. 00:37:19.328 --> 00:37:22.640 So it's like 1, 1, square root of 2. 00:37:22.640 --> 00:37:23.180 OK. 00:37:23.180 --> 00:37:25.280 So let's say I want the shortest path between the bottom left 00:37:25.280 --> 00:37:26.210 and the upper right. 00:37:26.210 --> 00:37:28.627 If I run Dijkstra's algorithm, we're in good shape, right? 00:37:28.627 --> 00:37:31.530 We get-- I'll let you do the computations at home. 00:37:31.530 --> 00:37:35.840 You'll get the path that is these two edges. 00:37:35.840 --> 00:37:38.000 But here's a really annoying thing. 00:37:38.000 --> 00:37:40.790 Let's say, instead, I wanted the shortest path 00:37:40.790 --> 00:37:44.840 from the upper left to the lower right. 00:37:44.840 --> 00:37:49.280 If I run Dijkstra's algorithm on this triangulated square, 00:37:49.280 --> 00:37:51.820 what's going to be the shortest path? 00:37:51.820 --> 00:37:52.320 Yeah. 00:37:52.320 --> 00:37:53.782 In fact, there's a bunch of them. 00:37:53.782 --> 00:37:55.740 One of them might go all the way down, and then 00:37:55.740 --> 00:37:57.238 all the way to the right. 00:37:57.238 --> 00:37:58.530 What's the length of this path? 00:37:58.530 --> 00:38:00.960 1, 2, 3, 4. 00:38:00.960 --> 00:38:02.700 Is that the length of the shortest path? 00:38:02.700 --> 00:38:04.080 Well, probably not. 00:38:04.080 --> 00:38:08.140 Well, we would like our shortest path to do something like that. 00:38:08.140 --> 00:38:11.290 But graphs don't know how to talk to triangles. 00:38:11.290 --> 00:38:13.210 And this is going to be a problem. 00:38:13.210 --> 00:38:16.240 In fact, it wasn't until fairly recently [INAUDIBLE] 00:38:16.240 --> 00:38:18.630 history terms that we were able to kind of work out 00:38:18.630 --> 00:38:20.640 the correct algorithm for the shortest 00:38:20.640 --> 00:38:22.867 path in a triangulated domain like this. 00:38:22.867 --> 00:38:24.700 And that's the runtime that we would expect. 00:38:24.700 --> 00:38:27.060 This is called MMP. 00:38:27.060 --> 00:38:29.940 I'm guessing Erik and Jason could do a better 00:38:29.940 --> 00:38:32.040 job describing it than I can. 00:38:32.040 --> 00:38:34.290 But the basic idea of the MMP algorithm 00:38:34.290 --> 00:38:35.220 actually is a really-- 00:38:35.220 --> 00:38:36.928 happens to be a nice extension of the way 00:38:36.928 --> 00:38:39.960 that we taught Dijkstra's algorithm in 6.006, 00:38:39.960 --> 00:38:42.160 because they really do keep track of these level 00:38:42.160 --> 00:38:43.710 sets of the distance function. 00:38:43.710 --> 00:38:46.050 But now, the level sets have to-- 00:38:46.050 --> 00:38:48.870 oops-- have to window and edge like that 00:38:48.870 --> 00:38:51.570 when I compute shortest path, which is a giant headache. 00:38:51.570 --> 00:38:53.070 This is one of these algorithms that 00:38:53.070 --> 00:38:55.920 was known in theory about 10 years before anybody bothered 00:38:55.920 --> 00:38:59.130 to implement it in a way that they could convince themselves 00:38:59.130 --> 00:39:01.170 it ran in n log n time. 00:39:01.170 --> 00:39:04.050 And nowadays, there's a cottage industry in computer graphics 00:39:04.050 --> 00:39:06.100 research papers to implement this and then 00:39:06.100 --> 00:39:07.350 speed it up in different ways. 00:39:07.350 --> 00:39:10.390 And sadly, the reality is that a different algorithm that we 00:39:10.390 --> 00:39:12.017 cover in 6.838 called fast marching-- 00:39:12.017 --> 00:39:14.100 which doesn't actually give you the shortest path, 00:39:14.100 --> 00:39:16.050 but some approximation thereof-- 00:39:16.050 --> 00:39:20.820 is faster, easier to use, and basically indistinguishable. 00:39:20.820 --> 00:39:24.840 In any event, in 6.838, we kind of 00:39:24.840 --> 00:39:28.410 have an interesting dual-mindset. 00:39:28.410 --> 00:39:29.940 We'll talk about a lot of algorithms 00:39:29.940 --> 00:39:33.300 that look like what we've done in whatever this class is-- 00:39:33.300 --> 00:39:35.180 6.006. 00:39:35.180 --> 00:39:37.680 But at the same time, start to have a more geometric flavor, 00:39:37.680 --> 00:39:41.013 and we don't worry quite as much about [INAUDIBLE].. 00:39:41.013 --> 00:39:42.930 So in our computation model, oftentimes, we're 00:39:42.930 --> 00:39:44.930 kind of OK with real numbers, because that's not 00:39:44.930 --> 00:39:45.847 where the headache is. 00:39:45.847 --> 00:39:47.888 And of course, when you write code in this class, 00:39:47.888 --> 00:39:49.650 you use double-precision floating-point. 00:39:49.650 --> 00:39:52.690 If you're more responsible, like in Jason's previous lecture, 00:39:52.690 --> 00:39:55.110 you should probably keep track of the number of operations 00:39:55.110 --> 00:39:56.777 to make sure that your error is counted. 00:39:56.777 --> 00:40:00.390 But I'm not sure that we really bother with that. 00:40:00.390 --> 00:40:04.740 In any event, this allows us to have two different mindsets. 00:40:04.740 --> 00:40:06.840 There's one mindset, which is discrete. 00:40:06.840 --> 00:40:09.220 There's another mindset, which is smooth. 00:40:09.220 --> 00:40:12.270 We think about understanding geometry, like these triangular 00:40:12.270 --> 00:40:14.975 domains, as an approximation of a smooth surface. 00:40:14.975 --> 00:40:17.350 And then we might want to do stuff like compute curvature 00:40:17.350 --> 00:40:19.590 and so on, which is really associated with computing 00:40:19.590 --> 00:40:21.060 derivatives, which of course, we'll 00:40:21.060 --> 00:40:23.400 have on these kinds of simplicial objects. 00:40:23.400 --> 00:40:26.160 And that leads to this really fun area of math and computer 00:40:26.160 --> 00:40:28.890 science, whatever, called discrete differential 00:40:28.890 --> 00:40:32.160 geometry, which sounds like a contradiction in terms. 00:40:32.160 --> 00:40:34.635 And it's something that we covered in quite some detail 00:40:34.635 --> 00:40:35.470 in this course. 00:40:35.470 --> 00:40:38.820 So we build up, all of calculus, that the only calculations 00:40:38.820 --> 00:40:40.530 you're left to do are on the vertices 00:40:40.530 --> 00:40:43.410 and edges and triangles of a triangle mesh. 00:40:43.410 --> 00:40:46.830 And get pretty far, including some constructions of topology, 00:40:46.830 --> 00:40:48.990 like the Duran complex, and so on. 00:40:48.990 --> 00:40:51.990 I would argue, actually, if you take our course and then 00:40:51.990 --> 00:40:53.500 the differential geometry courses 00:40:53.500 --> 00:40:56.783 in that department, somehow, some of the indices 00:40:56.783 --> 00:40:58.950 and headaches that you often encounter in that world 00:40:58.950 --> 00:41:00.630 are much more concrete when you try 00:41:00.630 --> 00:41:01.987 to make them work on a mesh. 00:41:01.987 --> 00:41:04.320 In any event, I think I've already spent all of my time. 00:41:04.320 --> 00:41:09.070 I can tell you a little bit about research in our group. 00:41:09.070 --> 00:41:12.250 I really lead kind of a weird, extremely [INAUDIBLE] group, 00:41:12.250 --> 00:41:15.210 where some of our students are essentially theory students-- 00:41:15.210 --> 00:41:17.050 touch your keyboard. 00:41:17.050 --> 00:41:17.560 I'm sorry. 00:41:17.560 --> 00:41:19.940 It was a reflex. 00:41:19.940 --> 00:41:21.050 But it was fast. 00:41:21.050 --> 00:41:21.550 All right. 00:41:21.550 --> 00:41:23.650 So we have some students whose background 00:41:23.650 --> 00:41:25.320 is in math, other ones that we're 00:41:25.320 --> 00:41:27.070 in autonomous driving industry and decided 00:41:27.070 --> 00:41:31.568 to come back and work in research. 00:41:31.568 --> 00:41:33.610 Because of that, we have this extremely broad set 00:41:33.610 --> 00:41:35.650 of research problems, everything from the sort 00:41:35.650 --> 00:41:38.830 of classic machine learning problems you might encounter 00:41:38.830 --> 00:41:41.650 in geometry world-- like if I have a self-driving car 00:41:41.650 --> 00:41:44.950 and I want to identify pedestrians and other cars 00:41:44.950 --> 00:41:48.550 on the road in an efficient and accurate fashion. 00:41:48.550 --> 00:41:51.010 By the way, part of that is machine learning 00:41:51.010 --> 00:41:52.847 and deep whatever, but there's another part, 00:41:52.847 --> 00:41:53.680 which is algorithms. 00:41:53.680 --> 00:41:56.560 Because actually, what comes into your LiDAR scanner 00:41:56.560 --> 00:41:59.110 is on the order of [INAUDIBLE] with points 00:41:59.110 --> 00:42:01.390 and some minuscule fraction of time. 00:42:01.390 --> 00:42:04.120 And time complexity of your learning algorithm 00:42:04.120 --> 00:42:06.127 actually is really critical to get it right, 00:42:06.127 --> 00:42:08.710 and something that there are a lot of open problems right now, 00:42:08.710 --> 00:42:11.560 because it's really not compatible with the hardware 00:42:11.560 --> 00:42:15.130 architecture that these cars often use. 00:42:15.130 --> 00:42:17.430 We also look at [INAUDIBLE] geometry problems, 00:42:17.430 --> 00:42:21.590 like if I give you data, can I find a geometric structure? 00:42:21.590 --> 00:42:24.550 So it's a classic example of natural language processing. 00:42:24.550 --> 00:42:28.540 When we use words like near and far, in terms of semantics 00:42:28.540 --> 00:42:29.930 and meaning, all the time. 00:42:29.930 --> 00:42:34.180 The question is, can we actually find an embedded of our word 00:42:34.180 --> 00:42:36.820 data into a geometric space to facilitate 00:42:36.820 --> 00:42:39.910 the statistical algorithms that we care about? 00:42:39.910 --> 00:42:42.820 And of course, we apply geometry to lots of practical problems, 00:42:42.820 --> 00:42:45.310 everything from meshing and scientific computing, 00:42:45.310 --> 00:42:47.920 which I think is sort of a classic one-- 00:42:47.920 --> 00:42:50.560 in fact, I think we're the first group that sort of enumerated 00:42:50.560 --> 00:42:54.170 all of the cool things that may happen to decahedral meshes, 00:42:54.170 --> 00:42:55.570 which is this bottom figure here. 00:42:55.570 --> 00:42:56.778 I should show this to people. 00:42:56.778 --> 00:42:59.194 There's some fun things to look at there. 00:42:59.194 --> 00:43:01.600 To other practical problems, like taking-- 00:43:01.600 --> 00:43:04.180 Erik took a zebra and folded it. 00:43:04.180 --> 00:43:08.050 We can take a zebra and move its texture onto a cat or a pig-- 00:43:08.050 --> 00:43:09.950 or, actually, off the side of the screen. 00:43:09.950 --> 00:43:12.408 But if we don't move the paper, [INAUDIBLE] for the 3D scan 00:43:12.408 --> 00:43:15.160 of what it might [INAUDIBLE]. 00:43:15.160 --> 00:43:18.610 In any event, in my five minutes remaining here, 00:43:18.610 --> 00:43:22.548 I thought I would dig into a little bit of detail of two-- 00:43:22.548 --> 00:43:24.340 or maybe one application, depending on when 00:43:24.340 --> 00:43:26.770 Jason and Erik get bored. 00:43:26.770 --> 00:43:29.200 And essentially, my message for you guys 00:43:29.200 --> 00:43:31.540 is, of course, [INAUDIBLE]. 00:43:31.540 --> 00:43:34.660 I'm not really a central CS theory group 00:43:34.660 --> 00:43:36.670 member here at MIT. 00:43:36.670 --> 00:43:39.970 But unfortunately for you guys, 6.006 is unavoidable. 00:43:39.970 --> 00:43:42.250 Even if you want to go into deep learning, statistics, 00:43:42.250 --> 00:43:43.292 whatever-- data science-- 00:43:43.292 --> 00:43:45.375 you're going to encounter the material that you've 00:43:45.375 --> 00:43:46.240 seen in this course. 00:43:46.240 --> 00:43:48.670 And in fact, it's really the bread and butter 00:43:48.670 --> 00:43:51.550 of just about everything everybody does here 00:43:51.550 --> 00:43:53.000 in this Data Center. 00:43:53.000 --> 00:43:55.780 So then, I'll give you two quick examples, one of which 00:43:55.780 --> 00:43:59.530 lifted from my teaching, one from my research. 00:43:59.530 --> 00:44:02.020 If you continue with me next fall, 00:44:02.020 --> 00:44:05.230 we'll teach 6.837, which is the Intro to Computer Graphics 00:44:05.230 --> 00:44:05.838 course. 00:44:05.838 --> 00:44:07.630 One thing that's always amazing to students 00:44:07.630 --> 00:44:09.047 is, these, algorithms that produce 00:44:09.047 --> 00:44:11.680 these really beautiful images, can fit in about 10, 00:44:11.680 --> 00:44:13.520 20 lines of code. 00:44:13.520 --> 00:44:15.630 So really, this is totally facetious, 00:44:15.630 --> 00:44:17.380 because if you want those beautiful images 00:44:17.380 --> 00:44:18.848 and you use those 20 lines of code, 00:44:18.848 --> 00:44:20.890 you'll be waiting until the death of the universe 00:44:20.890 --> 00:44:23.740 to actually compute these things. 00:44:23.740 --> 00:44:26.315 But in any event, one nice one for rendering-- so 00:44:26.315 --> 00:44:27.940 drawing a bunch of shapes [INAUDIBLE],, 00:44:27.940 --> 00:44:32.290 something called ray casting, or its better known cousin, 00:44:32.290 --> 00:44:33.310 ray tracing. 00:44:33.310 --> 00:44:35.590 Typically, the difference is whether your rays 00:44:35.590 --> 00:44:38.830 can bounce off of the surface and have a secondary thing. 00:44:38.830 --> 00:44:39.715 Right. 00:44:39.715 --> 00:44:41.090 Here's the ray casting algorithm. 00:44:41.090 --> 00:44:44.560 Let's say I have a scene built out of spheres and cubes. 00:44:44.560 --> 00:44:46.480 I'm going to have a for loop over every pixel 00:44:46.480 --> 00:44:47.920 on the computer screen. 00:44:47.920 --> 00:44:49.570 For every pixel, I've got to discover 00:44:49.570 --> 00:44:50.950 what color that should be. 00:44:50.950 --> 00:44:54.160 So I shoot a ray from my eyeball through that pixel 00:44:54.160 --> 00:44:57.330 and find the first object that it runs into. 00:44:57.330 --> 00:44:59.330 It's not so hard to intersect a line of a sphere 00:44:59.330 --> 00:45:01.090 or a line of a cube. 00:45:01.090 --> 00:45:02.370 So what is that algorithm? 00:45:02.370 --> 00:45:04.250 I've given it to you on the screen here. 00:45:04.250 --> 00:45:06.040 Not too bad to think about. 00:45:06.040 --> 00:45:08.290 And I think you guys are all extremely well 00:45:08.290 --> 00:45:10.850 equipped to analyze the runtime of this, 00:45:10.850 --> 00:45:13.210 which is roughly the number of pixels 00:45:13.210 --> 00:45:14.410 times the number of objects. 00:45:14.410 --> 00:45:15.820 Because for every pixel, I've got 00:45:15.820 --> 00:45:19.440 to decide what object the ray out of my eyeball hits first. 00:45:19.440 --> 00:45:21.660 So I need a for loop over [INAUDIBLE].. 00:45:21.660 --> 00:45:23.360 Make sense? 00:45:23.360 --> 00:45:23.860 Cool. 00:45:23.860 --> 00:45:27.590 So let's look at a basic rendering problem. 00:45:27.590 --> 00:45:31.080 In fact, Erik already secretly snuck this one in here. 00:45:31.080 --> 00:45:34.900 There's a very famous 3D model called the Stanford bunny. 00:45:34.900 --> 00:45:37.060 The Stanford bunny is actually a great example 00:45:37.060 --> 00:45:38.630 of a simplicial complex-- 00:45:38.630 --> 00:45:42.190 in fact, a manifold one, triangulated surface. 00:45:42.190 --> 00:45:45.430 Actually, I'm not sure it's manifold in its original form. 00:45:45.430 --> 00:45:47.000 But usually, it is. 00:45:47.000 --> 00:45:50.540 And this innocent-looking, extremely famous 3D model 00:45:50.540 --> 00:45:52.280 is actually quite pernicious. 00:45:52.280 --> 00:45:56.480 It's composed of 69,000 triangles. 00:45:56.480 --> 00:46:00.590 And if I wanted 1080p-- like a high def 00:46:00.590 --> 00:46:02.630 rendering of my triangle-- then, of course, 00:46:02.630 --> 00:46:04.920 there's two million pixels on the screen. 00:46:04.920 --> 00:46:06.860 So if we look at our big O expression, 00:46:06.860 --> 00:46:08.360 roughly, our computation time scales 00:46:08.360 --> 00:46:10.740 like the product of those two big numbers. 00:46:10.740 --> 00:46:13.070 So just to render this ugly gray bunny 00:46:13.070 --> 00:46:15.810 takes me a pretty large amount of time. 00:46:15.810 --> 00:46:17.810 And in fact, the reality-- by the way, the bunny 00:46:17.810 --> 00:46:19.760 is this famous test case in computer graphics, 00:46:19.760 --> 00:46:23.180 so if you take my class, you'll be rendering buddies all day. 00:46:23.180 --> 00:46:24.800 The reality is, we don't want just 00:46:24.800 --> 00:46:26.090 grayed, flat-shaded bunnies. 00:46:26.090 --> 00:46:29.570 We want bunnies that are transparent, and reflecting 00:46:29.570 --> 00:46:31.940 stuff, and I shoot my bunny with a bullet 00:46:31.940 --> 00:46:33.830 and shatters into a million pieces, and all 00:46:33.830 --> 00:46:35.370 of these cool things. 00:46:35.370 --> 00:46:37.470 So of course that, ray casting algorithm, 00:46:37.470 --> 00:46:40.310 with each one of these new graphics features I add, 00:46:40.310 --> 00:46:43.700 only adds to the time complexity of the technique 00:46:43.700 --> 00:46:44.775 that I implement. 00:46:44.775 --> 00:46:47.150 So pretty quickly-- and indeed, if you write your own ray 00:46:47.150 --> 00:46:49.970 tracer at home, which I strongly encourage you to do-- 00:46:49.970 --> 00:46:52.580 what you will discover is that a [INAUDIBLE] 00:46:52.580 --> 00:46:55.083 would be the technical phrase. 00:46:55.083 --> 00:46:56.250 What is our way out of this? 00:46:56.250 --> 00:46:59.240 Well, if you take it 837, you'll see 00:46:59.240 --> 00:47:00.770 that our way out of these problems, 00:47:00.770 --> 00:47:03.080 in graphics, is data structures and algorithms. 00:47:03.080 --> 00:47:05.240 It's completely unavoidable. 00:47:05.240 --> 00:47:07.580 For instance, obviously, we spent quite a bit of time 00:47:07.580 --> 00:47:10.670 in this course talking about AVL trees. 00:47:10.670 --> 00:47:13.970 In 837, we'll spend a big chunk of our tours talking 00:47:13.970 --> 00:47:16.790 about space partitioning trees. 00:47:16.790 --> 00:47:20.330 Here-- I actually forgot what kind of tree this is. 00:47:20.330 --> 00:47:23.180 I think it's a KD tree. 00:47:23.180 --> 00:47:24.650 Doesn't matter. 00:47:24.650 --> 00:47:26.450 In any event, one thing I could do 00:47:26.450 --> 00:47:29.810 is take all of the triangles of my bunny, 00:47:29.810 --> 00:47:33.230 and I could put the entire bunny in a giant cube 00:47:33.230 --> 00:47:35.780 with the property that the cube is outside the bunny. 00:47:35.780 --> 00:47:39.810 Let's say I cast a ray and the ray doesn't touch the cube. 00:47:39.810 --> 00:47:41.770 Can the ray touch the bunny? 00:47:41.770 --> 00:47:42.270 No, right? 00:47:42.270 --> 00:47:44.200 It zings right past it. 00:47:44.200 --> 00:47:46.680 So suddenly, I just saved myself a lot of computation time, 00:47:46.680 --> 00:47:47.180 right? 00:47:47.180 --> 00:47:49.620 I don't have to iterate over all the triangles inside 00:47:49.620 --> 00:47:51.942 of the body to see whether they hit the ray or not, 00:47:51.942 --> 00:47:53.400 because I already convinced myself, 00:47:53.400 --> 00:47:55.590 by this conservative test, that I 00:47:55.590 --> 00:47:59.830 didn't hit even the bounding box of the whole bunny. 00:47:59.830 --> 00:48:02.120 Well, that's sort of a nice order 1 speed-up. 00:48:02.120 --> 00:48:03.640 But depending on how big the bunny 00:48:03.640 --> 00:48:05.650 is relative to the size of my rendered image, 00:48:05.650 --> 00:48:09.350 that might not be a super useful efficiency test. 00:48:09.350 --> 00:48:10.760 But of course, what could I do? 00:48:10.760 --> 00:48:12.700 I could take the box containing the bunny, 00:48:12.700 --> 00:48:15.555 I could slice it in half, and now it's saying, 00:48:15.555 --> 00:48:17.680 does my ray hit the front or the back of the bunny? 00:48:17.680 --> 00:48:18.310 Or maybe both. 00:48:18.310 --> 00:48:21.530 That's where you've got to-- that's where things get gnarly. 00:48:21.530 --> 00:48:22.605 And so on. 00:48:22.605 --> 00:48:24.730 So now you have this nice recursive tree structure, 00:48:24.730 --> 00:48:26.740 where I keep taking the box containing my bunny 00:48:26.740 --> 00:48:29.620 and chopping it in half and placing-- 00:48:29.620 --> 00:48:32.750 in some sense, usually, the triangles-- 00:48:32.750 --> 00:48:35.090 maybe not the leaves of my tree, but [INAUDIBLE] that's 00:48:35.090 --> 00:48:36.510 probably good enough. 00:48:36.510 --> 00:48:39.790 You get a structure like what you see on the screen here. 00:48:39.790 --> 00:48:41.120 And why should you do that? 00:48:41.120 --> 00:48:44.710 Well, remember, it takes pn time to render my image of my bunny 00:48:44.710 --> 00:48:45.850 normally. 00:48:45.850 --> 00:48:48.850 Well, now, the picture is actually 00:48:48.850 --> 00:48:50.710 misleadingly suggestive. 00:48:50.710 --> 00:48:53.170 But you might think that, maybe, it takes roughly-- 00:48:53.170 --> 00:48:56.050 remember, n is the number of objects in my scene-- 00:48:56.050 --> 00:48:58.750 p log n time to render my bunny now, 00:48:58.750 --> 00:49:01.600 because I can kind of traverse the tree of objects 00:49:01.600 --> 00:49:02.930 in my scene. 00:49:02.930 --> 00:49:05.500 Of course, notice, I put a question mark here. 00:49:05.500 --> 00:49:08.132 And the devil's in the details here. 00:49:08.132 --> 00:49:10.090 In fact, I think computer graphics people often 00:49:10.090 --> 00:49:13.580 believe that their rendering algorithm takes p log n time. 00:49:13.580 --> 00:49:16.630 That's often not possible, although kind 00:49:16.630 --> 00:49:18.070 of an interesting question, which 00:49:18.070 --> 00:49:21.370 is, the heuristics they use for building these sorts of trees 00:49:21.370 --> 00:49:24.050 often do, on average, give them log n time. 00:49:24.050 --> 00:49:25.750 And so there's something about the data 00:49:25.750 --> 00:49:28.733 that's making this problem easier than it might seem. 00:49:28.733 --> 00:49:31.150 So we'll dig into that a little bit in the graphics class. 00:49:31.150 --> 00:49:33.275 Of course, you're not going to proof as many bounds 00:49:33.275 --> 00:49:34.915 as you might in a theory course. 00:49:34.915 --> 00:49:36.790 But we're certainly building on the intuition 00:49:36.790 --> 00:49:39.370 that we've seen in this class to build on practical data 00:49:39.370 --> 00:49:40.023 structures. 00:49:40.023 --> 00:49:41.815 And these data structures appear everywhere 00:49:41.815 --> 00:49:43.150 in computer graphics. 00:49:43.150 --> 00:49:47.620 For instance, directed acyclic graphs 00:49:47.620 --> 00:49:50.650 appear all over the place in computer graphics literature 00:49:50.650 --> 00:49:52.300 to describe 3D scenes. 00:49:52.300 --> 00:49:55.450 For example, this classroom is a stark reminder 00:49:55.450 --> 00:49:58.630 of why we need DAGs and computer graphics, 00:49:58.630 --> 00:50:00.580 because we have all of these empty seats here, 00:50:00.580 --> 00:50:02.990 and they're all copies of one another. 00:50:02.990 --> 00:50:06.310 So would it make sense for me to store however many, 00:50:06.310 --> 00:50:08.920 like, 100 3D molds of the same chair? 00:50:08.920 --> 00:50:10.790 Probably not. 00:50:10.790 --> 00:50:12.110 So instead, what do I do? 00:50:12.110 --> 00:50:15.220 I store one instance of a chair, and then some instructions 00:50:15.220 --> 00:50:18.840 on how to tile it into my entire scene. 00:50:18.840 --> 00:50:20.730 One way that I can do that is to think 00:50:20.730 --> 00:50:22.890 of there being a node in a graph which 00:50:22.890 --> 00:50:25.290 knows how to draw one chair. 00:50:25.290 --> 00:50:27.210 And now, I can have a bunch of different nodes 00:50:27.210 --> 00:50:29.252 in my scene for all of the instances of the chair 00:50:29.252 --> 00:50:32.032 and then store a different transformation for each one. 00:50:32.032 --> 00:50:33.990 So if you think about the graph structure here, 00:50:33.990 --> 00:50:37.080 each of those ones is going to point into the same 3D model 00:50:37.080 --> 00:50:38.830 of the chair for rendering. 00:50:38.830 --> 00:50:41.522 And that makes a directed acyclic graph structure 00:50:41.522 --> 00:50:43.980 called a scene graph, which we'll spend quite a bit of time 00:50:43.980 --> 00:50:46.890 talking about in 837, how to traverse and construct 00:50:46.890 --> 00:50:49.950 all that good stuff. 00:50:49.950 --> 00:50:52.380 And there are lots of different models of computation 00:50:52.380 --> 00:50:54.120 in that universe, as well. 00:50:54.120 --> 00:50:58.500 Your graphics card is a very specific kind 00:50:58.500 --> 00:51:00.930 of parallel processor that's kind of like Lucille 00:51:00.930 --> 00:51:03.960 Ball on the conveyor belt, hammering at the same object 00:51:03.960 --> 00:51:05.080 over and over again. 00:51:05.080 --> 00:51:07.205 But if you ask it to do anything other than the one 00:51:07.205 --> 00:51:09.490 thing it knows how to do to a bunch of data at a time, 00:51:09.490 --> 00:51:11.650 then all of your computation grinds to a halt. 00:51:11.650 --> 00:51:14.310 This is called Single Instruction Multiple Data 00:51:14.310 --> 00:51:16.350 parallelism, SIMD. 00:51:16.350 --> 00:51:17.940 Numerical algorithms matter a lot 00:51:17.940 --> 00:51:20.190 for things like fluid simulation. 00:51:20.190 --> 00:51:24.420 And approximation algorithms are quite critical, too. 00:51:24.420 --> 00:51:26.490 In computer graphics, the complexity 00:51:26.490 --> 00:51:29.610 is kind of interesting, because of course, your eyeball 00:51:29.610 --> 00:51:32.730 is sensitive to about 29.97 frames 00:51:32.730 --> 00:51:35.880 per second worth of material. 00:51:35.880 --> 00:51:39.158 You can choose that time to do really well-rendering one 00:51:39.158 --> 00:51:41.700 object, but then you take out of the time rendering something 00:51:41.700 --> 00:51:42.960 else. 00:51:42.960 --> 00:51:45.090 There's kind of an interesting conservation law 00:51:45.090 --> 00:51:46.715 that you have to balance when you solve 00:51:46.715 --> 00:51:49.680 these kinds of problems, which is an interesting balance, now, 00:51:49.680 --> 00:51:52.920 between complexity and runtime of your algorithm 00:51:52.920 --> 00:51:54.180 and perception. 00:51:54.180 --> 00:51:56.970 What things can you get away with when you draw a scene? 00:51:56.970 --> 00:51:59.492 And maybe I can do tons of extra computation 00:51:59.492 --> 00:52:01.700 to get that extra shadow, but it's just not worth it. 00:52:04.310 --> 00:52:06.770 I'll quickly sketch out another completely different 00:52:06.770 --> 00:52:09.960 application of the material that we've covered 00:52:09.960 --> 00:52:12.450 in 6.006 from my own research. 00:52:12.450 --> 00:52:13.520 Again, just like Erik-- 00:52:13.520 --> 00:52:15.728 I guess, in a funny way, both of our groups, I think, 00:52:15.728 --> 00:52:18.620 are kind of broad in terms of subject material, rather than-- 00:52:18.620 --> 00:52:20.720 some of our colleagues have really laser focus 00:52:20.720 --> 00:52:23.780 on one topic or another. 00:52:23.780 --> 00:52:27.280 Another Research area that I have sort of backed into 00:52:27.280 --> 00:52:29.780 is the area of political redistricting. 00:52:29.780 --> 00:52:31.905 This is relevant in the United States. 00:52:31.905 --> 00:52:33.140 Recently, I've been reading this great proposal 00:52:33.140 --> 00:52:35.432 about other countries, which is really interesting, how 00:52:35.432 --> 00:52:37.550 they do this stuff. 00:52:37.550 --> 00:52:40.700 In the US, when we vote for people in Congress-- 00:52:40.700 --> 00:52:42.900 by the way, not necessarily for presidents. 00:52:42.900 --> 00:52:44.870 This is a common misconception. 00:52:44.870 --> 00:52:48.470 But certainly for Congress, your state 00:52:48.470 --> 00:52:50.420 is divided into little regions, each of which 00:52:50.420 --> 00:52:53.040 elects one member of the House. 00:52:53.040 --> 00:52:56.975 And there's sort of a subtle problem if you're not 00:52:56.975 --> 00:52:58.350 used to thinking about it, or one 00:52:58.350 --> 00:53:00.642 that's staring you in the face and screaming, depending 00:53:00.642 --> 00:53:03.823 on how often you read the news and politics. 00:53:03.823 --> 00:53:05.490 There is an issue called gerrymandering, 00:53:05.490 --> 00:53:09.030 where your legislature draws the lines for what area on the map 00:53:09.030 --> 00:53:11.640 elects a member of Congress. 00:53:11.640 --> 00:53:13.860 And depending on how you draw the lines, 00:53:13.860 --> 00:53:15.420 you can engineer different results 00:53:15.420 --> 00:53:17.220 for who's likely to get elected. 00:53:17.220 --> 00:53:19.140 So for instance, maybe there's some minority. 00:53:19.140 --> 00:53:21.690 I can cluster them all together into one voting district. 00:53:21.690 --> 00:53:23.460 Then they will only get the opportunity 00:53:23.460 --> 00:53:24.690 to elect one person. 00:53:24.690 --> 00:53:28.770 But maybe, if I divide the space where they live into two, 00:53:28.770 --> 00:53:30.780 I managed to engineer two districts 00:53:30.780 --> 00:53:33.060 with a high probability of electing somebody 00:53:33.060 --> 00:53:36.270 with their political interests in mind. 00:53:36.270 --> 00:53:38.760 It turns out that political redistricting, 00:53:38.760 --> 00:53:41.430 in a broad sense, is a great problem, computationally. 00:53:41.430 --> 00:53:43.270 Even if you're a totally heartless theorist, 00:53:43.270 --> 00:53:45.282 there are some really fun problems here. 00:53:45.282 --> 00:53:46.740 So for example, the state of Iowa-- 00:53:46.740 --> 00:53:50.010 we all pick on Iowa because it has a unique law, which 00:53:50.010 --> 00:53:52.530 is that districts have to be built out of counties, which 00:53:52.530 --> 00:53:54.790 are much larger than the typical census unit, 00:53:54.790 --> 00:53:56.710 so it computationally is easier. 00:53:56.710 --> 00:53:59.813 But even in Iowa, which is a giant grid-- 00:53:59.813 --> 00:54:01.980 with the exception of one shift in the middle, which 00:54:01.980 --> 00:54:04.800 is fascinating to me-- 00:54:04.800 --> 00:54:06.870 I know [INAUDIBLE], fun fact. 00:54:06.870 --> 00:54:08.880 Literally, people were making the map of Iowa, 00:54:08.880 --> 00:54:10.680 and they worked from the bottom up and the top down, 00:54:10.680 --> 00:54:13.260 and it meets in the middle and their grids were shifted, 00:54:13.260 --> 00:54:14.790 and now we're stuck with that. 00:54:14.790 --> 00:54:16.950 And it has an interesting effect on the topology of the graph, 00:54:16.950 --> 00:54:18.908 because it looks like squares, but then there's 00:54:18.908 --> 00:54:20.460 triangles in the middle. 00:54:20.460 --> 00:54:23.670 But in any event, even though there's 00:54:23.670 --> 00:54:25.530 only 99 counties in four districts, 00:54:25.530 --> 00:54:28.530 there's approximately quintillions of possible ways 00:54:28.530 --> 00:54:31.620 you can divide that state into four contiguous districts that 00:54:31.620 --> 00:54:33.630 satisfy the rules as they were-- 00:54:33.630 --> 00:54:38.472 at least, if you read the code literally in the law. 00:54:38.472 --> 00:54:39.930 It seems like computers are useful, 00:54:39.930 --> 00:54:42.240 but unfortunately, it's a little subtle how. 00:54:42.240 --> 00:54:44.730 For instance, there's no single "best" districting 00:54:44.730 --> 00:54:46.075 plan out there. 00:54:46.075 --> 00:54:48.450 I can't think of a single state with a law that gives you 00:54:48.450 --> 00:54:54.060 an objective function, similar to whatever cute characters 00:54:54.060 --> 00:54:55.530 that we've had in 6.006. 00:54:55.530 --> 00:54:57.960 They often have very clear objectives in life, 00:54:57.960 --> 00:55:00.060 but unfortunately, redistricting, that's 00:55:00.060 --> 00:55:01.050 very rarely the case. 00:55:01.050 --> 00:55:03.570 You have to balance contiguity, population balance, 00:55:03.570 --> 00:55:07.080 compactness, all of these different things. 00:55:07.080 --> 00:55:09.480 Reality check number two is that, even if somebody 00:55:09.480 --> 00:55:11.670 did give you an objective function, 00:55:11.670 --> 00:55:13.870 for just about any interesting objective function, 00:55:13.870 --> 00:55:17.010 it's very obvious that generating the best possible 00:55:17.010 --> 00:55:20.190 districting plan is NP-hard. 00:55:20.190 --> 00:55:21.840 And by the way, it doesn't even matter, 00:55:21.840 --> 00:55:24.570 because the law doesn't say that computers have 00:55:24.570 --> 00:55:26.340 to draw the best districts. 00:55:26.340 --> 00:55:28.770 Even if P equals NP really could extract 00:55:28.770 --> 00:55:32.453 the best possible districting plan using an algorithm, 00:55:32.453 --> 00:55:34.620 it doesn't mean you have to use it, at least the way 00:55:34.620 --> 00:55:36.330 the law's written now. 00:55:36.330 --> 00:55:38.860 Interestingly, this is not true in certain parts of Mexico, 00:55:38.860 --> 00:55:41.068 where they actually make you compare your districting 00:55:41.068 --> 00:55:42.907 plan against a computer-generated one, which 00:55:42.907 --> 00:55:44.490 is philosophically really interesting, 00:55:44.490 --> 00:55:46.746 although in practice, it doesn't work terribly well. 00:55:49.350 --> 00:55:52.233 Our researchers studied analysis of districting plans instead. 00:55:52.233 --> 00:55:54.150 So instead of running a piece of software that 00:55:54.150 --> 00:55:56.280 takes in your state, draws your districts, 00:55:56.280 --> 00:55:57.540 and then you're done-- 00:55:57.540 --> 00:55:59.460 instead, we ask statistical questions 00:55:59.460 --> 00:56:01.770 about, I propose a districting plan, 00:56:01.770 --> 00:56:03.870 what does it look like relative to the space 00:56:03.870 --> 00:56:07.387 of the possibilities? 00:56:07.387 --> 00:56:08.970 So that, of course, begs the question, 00:56:08.970 --> 00:56:10.570 what are the possibilities? 00:56:10.570 --> 00:56:13.020 So these are the connected graph partitions. 00:56:13.020 --> 00:56:15.990 Meaning, you have a graph, and you take the vertices 00:56:15.990 --> 00:56:18.158 and you cluster them together in a way where they're 00:56:18.158 --> 00:56:19.200 connected to one another. 00:56:19.200 --> 00:56:22.410 The one thing that we all agree on-- actually, philosophically, 00:56:22.410 --> 00:56:23.862 it's questionable why-- 00:56:23.862 --> 00:56:25.320 is that you should be able to start 00:56:25.320 --> 00:56:27.780 at any point in your district and walk to any other one 00:56:27.780 --> 00:56:29.277 without leaving. 00:56:29.277 --> 00:56:30.735 These days, with the internet, it's 00:56:30.735 --> 00:56:33.270 not clear that that's actually the best criterion. 00:56:33.270 --> 00:56:34.980 But that's a law that, I think, is never 00:56:34.980 --> 00:56:39.828 going to get passed in the near future. 00:56:39.828 --> 00:56:41.370 Anyway, I think I'm out of time, so I 00:56:41.370 --> 00:56:44.543 don't think I'll walk you guys through the theory here. 00:56:44.543 --> 00:56:45.960 Maybe I'll leave it in the slides. 00:56:45.960 --> 00:56:48.390 There's a sort of very simple proof 00:56:48.390 --> 00:56:51.030 that can show that, at least the very simplest thing you might 00:56:51.030 --> 00:56:52.905 think of for analyzing your districting plan, 00:56:52.905 --> 00:56:55.290 which is to say, you propose a plan, 00:56:55.290 --> 00:56:57.810 and now, I want your plan to be at least as 00:56:57.810 --> 00:57:01.350 good, under some axis, as it's a randomly drawn one 00:57:01.350 --> 00:57:03.810 from the space of all possible connected partitions-- 00:57:03.810 --> 00:57:06.397 all of the possible ways I could draw the lines. 00:57:06.397 --> 00:57:07.980 Well, then, it might be useful to have 00:57:07.980 --> 00:57:10.510 a piece of software that could just randomly draw 00:57:10.510 --> 00:57:11.760 such a thing. 00:57:11.760 --> 00:57:13.260 So in other words, to draw something 00:57:13.260 --> 00:57:15.300 where the probability of any one partition 00:57:15.300 --> 00:57:18.060 is 1 over the number of partitions. 00:57:18.060 --> 00:57:19.453 This seems innocent. 00:57:19.453 --> 00:57:21.120 In fact, there's a number of papers that 00:57:21.120 --> 00:57:23.010 claim to do things like this. 00:57:23.010 --> 00:57:27.570 But it turns out that it's computationally difficult, 00:57:27.570 --> 00:57:29.970 assuming that you believe that P doesn't equal NP. 00:57:29.970 --> 00:57:32.550 So I'll maybe leave some suggestive pictures 00:57:32.550 --> 00:57:34.440 in the slide that we can-- 00:57:34.440 --> 00:57:38.760 if you guys text me, or if we have a professor-student chat, 00:57:38.760 --> 00:57:41.160 I'm happy to sketch it out to you then. 00:57:41.160 --> 00:57:43.170 There's a very nice, easy proof that 00:57:43.170 --> 00:57:45.840 reduces this to Hamiltonian cycle, 00:57:45.840 --> 00:57:48.473 and shows you that maybe you shouldn't trust these tools, 00:57:48.473 --> 00:57:50.265 as much as they're argued about, literally, 00:57:50.265 --> 00:57:52.380 in the Supreme Court a couple of months ago. 00:57:52.380 --> 00:57:53.850 By the way, it was pretty fun. 00:57:53.850 --> 00:57:57.420 Our expert report was referenced in the defense of the case 00:57:57.420 --> 00:57:58.565 last summer. 00:57:58.565 --> 00:57:59.940 And when you read the discussion, 00:57:59.940 --> 00:58:01.320 you can see the judges trying to talk 00:58:01.320 --> 00:58:02.550 their way around complexity. 00:58:02.550 --> 00:58:07.677 And it's an interesting, if somewhat dry, read. 00:58:07.677 --> 00:58:09.510 In any event, that's just the starting point 00:58:09.510 --> 00:58:11.385 for our research, which says that, of course, 00:58:11.385 --> 00:58:13.080 these sampling problems are really hard. 00:58:13.080 --> 00:58:14.880 The questions is, what can you do? 00:58:14.880 --> 00:58:17.910 [INAUDIBLE] or not. 00:58:17.910 --> 00:58:20.800 But the real message here is, of course, 00:58:20.800 --> 00:58:22.440 that this course is unavoidable. 00:58:22.440 --> 00:58:24.360 Even in these extremely applied problems 00:58:24.360 --> 00:58:27.990 showing up in court cases or on your graphics card, you still-- 00:58:27.990 --> 00:58:30.540 complexity and algorithms and data structures 00:58:30.540 --> 00:58:33.230 are going to come back to play. 00:58:33.230 --> 00:58:36.090 So with that, our other two instructors 00:58:36.090 --> 00:58:40.770 up here for our final farewell-- suitably distance ourselves. 00:58:40.770 --> 00:58:42.660 ERIK DEMAINE: So algorithms are everywhere. 00:58:42.660 --> 00:58:44.625 I hope you enjoyed this class. 00:58:44.625 --> 00:58:47.250 It's been a lot of fun teaching you and having you as students. 00:58:47.250 --> 00:58:49.050 Even though you're not here physically in the room, 00:58:49.050 --> 00:58:50.460 we still feel your presence. 00:58:50.460 --> 00:58:53.680 And I look forward to seeing you all soon. 00:58:53.680 --> 00:58:57.040 Thanks for being a part of this fun thing. 00:58:57.040 --> 00:58:59.610 I want to thank our two-- 00:58:59.610 --> 00:59:03.370 my two co-instructors for an awesome time this semester. 00:59:03.370 --> 00:59:06.330 It's been a lot of fun teaching to you guys. 00:59:06.330 --> 00:59:08.575 JASON KU: Thanks for spending 006 with us this term. 00:59:08.575 --> 00:59:09.450 JUSTIN SOLOMON: Yeah. 00:59:09.450 --> 00:59:09.850 Thank you. 00:59:09.850 --> 00:59:11.260 And hopefully we'll see you again soon. 00:59:11.260 --> 00:59:12.010 ERIK DEMAINE: Bye. 00:59:12.010 --> 00:59:13.270 JASON KU: Bye.