WEBVTT 00:00:00.530 --> 00:00:02.960 The following content is provided under a Creative 00:00:02.960 --> 00:00:04.370 Commons license. 00:00:04.370 --> 00:00:07.410 Your support will help MIT OpenCourseWare continue to 00:00:07.410 --> 00:00:11.060 offer high quality educational resources for free. 00:00:11.060 --> 00:00:13.960 To make a donation or view additional materials from 00:00:13.960 --> 00:00:18.940 hundreds of MIT courses, visit MIT OpenCourseWare at 00:00:18.940 --> 00:00:20.190 ocw.mit.edu. 00:00:24.368 --> 00:00:25.620 PROFESSOR: So hello. 00:00:28.500 --> 00:00:31.380 Today I want to talk about, and I want to finish talking 00:00:31.380 --> 00:00:32.914 about, search algorithms. 00:00:35.530 --> 00:00:38.710 So last time we started to think about a framework within 00:00:38.710 --> 00:00:42.030 which to think about search and the important thing was to 00:00:42.030 --> 00:00:45.350 figure out a way to be systematic about it. 00:00:45.350 --> 00:00:48.280 So we figured out a way to organize the way we think 00:00:48.280 --> 00:00:51.400 about searching by way of a tree. 00:00:51.400 --> 00:00:54.270 Put all the possible places where we could be in the 00:00:54.270 --> 00:00:58.380 search, consider all the possible actions that we could 00:00:58.380 --> 00:01:00.970 take, so if we started it at A, there are two different 00:01:00.970 --> 00:01:03.980 actions we could've taken, we could have gone to B or D 00:01:03.980 --> 00:01:08.750 Think of the actions as the edges of the graph and then 00:01:08.750 --> 00:01:12.100 think about where we land. 00:01:12.100 --> 00:01:16.510 Then, by way of that graph, think about the shortest path 00:01:16.510 --> 00:01:17.990 to the goal. 00:01:17.990 --> 00:01:23.690 So that was the idea and the big outcome was order matters. 00:01:23.690 --> 00:01:29.030 So if we were to construct an agenda, which is the list of 00:01:29.030 --> 00:01:33.270 nodes that we are currently considering, if we started at 00:01:33.270 --> 00:01:37.660 A, we would start by putting A on the agenda. 00:01:37.660 --> 00:01:41.350 Then we would pop A out of the agenda and replace it with its 00:01:41.350 --> 00:01:45.240 children, its children are AB and AD. 00:01:45.240 --> 00:01:48.820 If the algorithm was replaced, the first node in the agenda 00:01:48.820 --> 00:01:51.620 by the children, the first node is AB. 00:01:51.620 --> 00:01:55.760 So then we would pop AB and replace it with its children, 00:01:55.760 --> 00:01:57.490 AB has children ACE, etc. 00:02:02.110 --> 00:02:04.350 And the result would be something that we call a depth 00:02:04.350 --> 00:02:07.890 first search, because what's happening is we're following 00:02:07.890 --> 00:02:14.400 line lines deeply before we look crosswise. 00:02:14.400 --> 00:02:16.610 And there's a million varieties of this that you 00:02:16.610 --> 00:02:17.730 could think of. 00:02:17.730 --> 00:02:20.010 You would get the same kind of algorithm if you replaced the 00:02:20.010 --> 00:02:22.900 last node by its children. 00:02:22.900 --> 00:02:26.210 Then you would start with A, replace it by its children, 00:02:26.210 --> 00:02:27.870 which is still B,D -- 00:02:27.870 --> 00:02:32.900 but now expand D in terms of its children. 00:02:32.900 --> 00:02:37.510 Then you'd take the last trial, expand it and we would 00:02:37.510 --> 00:02:39.300 get another depth search. 00:02:39.300 --> 00:02:43.960 So the idea is whatever order you choose affects the 00:02:43.960 --> 00:02:46.210 solution that you find. 00:02:46.210 --> 00:02:49.470 Generally, we're interested in finding a search that locates 00:02:49.470 --> 00:02:56.820 the best, shortest path, and so a good method is to remove 00:02:56.820 --> 00:02:59.250 the first node from the agenda and add the 00:02:59.250 --> 00:03:01.730 children to the end. 00:03:01.730 --> 00:03:07.890 That's a cube-based ordering where the first out 00:03:07.890 --> 00:03:10.370 is the first in. 00:03:10.370 --> 00:03:13.600 Then if you imagine starting at A, replacing it by its 00:03:13.600 --> 00:03:18.680 children, B,D, take the first guy out-- that's AB-- 00:03:18.680 --> 00:03:22.730 consider its children and put them at the end of the list. 00:03:22.730 --> 00:03:26.930 Then we go back and expand AD before we think about the 00:03:26.930 --> 00:03:31.500 children of AB and so the result-- if you just follow 00:03:31.500 --> 00:03:32.930 the red up here-- 00:03:32.930 --> 00:03:36.850 the result of that search is what we call breadth first. 00:03:36.850 --> 00:03:39.960 So we systematically propagate down the search tree looking 00:03:39.960 --> 00:03:42.290 at short paths first. 00:03:42.290 --> 00:03:45.460 So that's the idea, the idea is search is easy, you 00:03:45.460 --> 00:03:51.130 organize it around one of these graphs and just 00:03:51.130 --> 00:03:53.980 systematically run through the search by keeping track of 00:03:53.980 --> 00:03:57.290 what we call the agenda, the nodes under consideration, and 00:03:57.290 --> 00:04:01.140 the only trick is that order matters. 00:04:01.140 --> 00:04:06.270 We found two useful orders last time, first in, first out 00:04:06.270 --> 00:04:10.180 and last in, first out, one of those giving depth first, 00:04:10.180 --> 00:04:11.750 which is generally not a good idea. 00:04:11.750 --> 00:04:13.450 The other giving breadth first, which is generally a 00:04:13.450 --> 00:04:14.770 much better idea. 00:04:14.770 --> 00:04:17.959 Today what I want to do is generalize that structure to 00:04:17.959 --> 00:04:22.400 take into account a much more flexible group of problems. 00:04:22.400 --> 00:04:26.930 That'll give rise to something we call uniform cost search 00:04:26.930 --> 00:04:28.420 and the other thing that I want to think about 00:04:28.420 --> 00:04:31.170 is, again, the order. 00:04:31.170 --> 00:04:34.120 By thinking about the order, we can drastically improve the 00:04:34.120 --> 00:04:38.610 efficiency of a search and that idea gives rise to 00:04:38.610 --> 00:04:42.100 something that we'll call heuristics. 00:04:42.100 --> 00:04:48.740 So the idea then that I want to look at first in terms of 00:04:48.740 --> 00:04:53.270 uniform cost search is the idea that so far, we've only 00:04:53.270 --> 00:04:56.580 looked at problems where the cost of each 00:04:56.580 --> 00:05:00.810 child is the same. 00:05:00.810 --> 00:05:06.280 We were only looking at how many children in total, how 00:05:06.280 --> 00:05:10.740 many generations did we have to go through to get from the 00:05:10.740 --> 00:05:13.650 starting point to the goal. 00:05:13.650 --> 00:05:16.330 That's an important class of problems, but it's by no means 00:05:16.330 --> 00:05:19.180 the only important class of problems and in fact, the most 00:05:19.180 --> 00:05:21.590 trivial problems you can think of don't fall into that class. 00:05:21.590 --> 00:05:25.170 So for example, imagine that what we were doing, so I 00:05:25.170 --> 00:05:28.300 motivated the entire problem last time in terms of 00:05:28.300 --> 00:05:31.320 searching for a path on a Manhattan Grid. 00:05:31.320 --> 00:05:36.240 So if I wanted to go from A to I, where all the distances are 00:05:36.240 --> 00:05:40.410 equal, then minimizing the number of generations, 00:05:40.410 --> 00:05:42.420 minimizing the number of intersections that I go 00:05:42.420 --> 00:05:44.480 through, will give rise to the best search. 00:05:44.480 --> 00:05:48.570 However, imagine that one particular node 00:05:48.570 --> 00:05:52.060 is way off the map. 00:05:52.060 --> 00:05:55.000 Then the number of generations that I go through is obviously 00:05:55.000 --> 00:05:58.670 not the right answer because there's a penalty for taking a 00:05:58.670 --> 00:06:02.060 path that goes through C because the distance between B 00:06:02.060 --> 00:06:04.540 and C is so much bigger than the distance, for example, 00:06:04.540 --> 00:06:08.050 from D to G. 00:06:08.050 --> 00:06:10.400 So the first thing that I want to look at is how do we 00:06:10.400 --> 00:06:12.610 incorporate that kind of new information 00:06:12.610 --> 00:06:15.190 into the search algorithm? 00:06:15.190 --> 00:06:19.780 So before I do that, think about how the 00:06:19.780 --> 00:06:21.210 breadth-first search-- 00:06:21.210 --> 00:06:23.270 the thing we found last time that was the best-- 00:06:23.270 --> 00:06:25.650 breadth-first search with dynamic programming -- 00:06:25.650 --> 00:06:28.930 think about how it would approach the problem and think 00:06:28.930 --> 00:06:33.020 about as we go through step by step, what is it doing wrong? 00:06:33.020 --> 00:06:33.300 OK? 00:06:33.300 --> 00:06:35.410 So I'm going to go through an algorithm that is 00:06:35.410 --> 00:06:37.850 known not to work -- 00:06:37.850 --> 00:06:40.660 with the idea that you're supposed to identify as I'm 00:06:40.660 --> 00:06:44.770 doing that what step was wrong. 00:06:44.770 --> 00:06:48.970 So imagine that I'm doing this and then I'm going to compare 00:06:48.970 --> 00:06:51.130 it in a moment to C being off the map. 00:06:53.860 --> 00:06:58.490 So if I do this problem with dynamic programming, I have to 00:06:58.490 --> 00:07:02.710 keep track of how many nodes I already visited and I have to 00:07:02.710 --> 00:07:05.270 keep track of all the nodes under consideration. 00:07:05.270 --> 00:07:08.030 The nodes under consideration is what we call the agenda and 00:07:08.030 --> 00:07:11.730 I will call the list of nodes that we're keeping track of 00:07:11.730 --> 00:07:14.020 for dynamic programming, I'll call that the visited list 00:07:14.020 --> 00:07:17.240 because we'll add nodes to the list. 00:07:17.240 --> 00:07:21.200 We'll add states to the list as we visit them. 00:07:21.200 --> 00:07:24.820 So we start out the algorithm with node A being on the 00:07:24.820 --> 00:07:30.470 agenda, we're trying to go to node I. And by the time I've 00:07:30.470 --> 00:07:34.070 started, I've already visited A. So the starting point is 00:07:34.070 --> 00:07:36.980 that the visited list has one element in at A, the agenda 00:07:36.980 --> 00:07:42.240 has one element in it, A. So the algorithm is going to be 00:07:42.240 --> 00:07:46.070 pop the first guy out of the agenda and add the children to 00:07:46.070 --> 00:07:50.520 the end, paying attention to the visited list. 00:07:50.520 --> 00:07:55.970 So pop A out of the agenda, the children of A are B and D. 00:07:55.970 --> 00:07:59.530 As I visit them, they get added to visited list, B and 00:07:59.530 --> 00:08:07.460 D. So I pop the first person out, that's AB. 00:08:07.460 --> 00:08:11.080 Then I want to think about the children of AB, that's ACE. 00:08:11.080 --> 00:08:16.310 A is already visited, so I don't need to add that again, 00:08:16.310 --> 00:08:19.410 but C and E are not, so I add them and add them to the 00:08:19.410 --> 00:08:20.660 visited last. 00:08:23.250 --> 00:08:29.230 Then I pop AD out, well the children are AEG. 00:08:29.230 --> 00:08:32.950 A and E are in the list already, G is not, so I end up 00:08:32.950 --> 00:08:35.100 adding G to the list. 00:08:38.580 --> 00:08:43.460 Next is to pop out C. The children of C are B and F. B 00:08:43.460 --> 00:08:46.010 was in the list, F was not so I add the trial that 00:08:46.010 --> 00:08:47.260 has F at the end. 00:08:51.000 --> 00:08:56.070 Then the next one is E. E has children BDFH. 00:08:56.070 --> 00:09:05.930 B,D,F, the only new one is H, then G. Take G out, the 00:09:05.930 --> 00:09:08.230 children of G are D and H but they're already in a visited 00:09:08.230 --> 00:09:09.700 list, so I don't need to worry about them. 00:09:13.130 --> 00:09:20.850 Then A,B,C,F, so F is this guy, C,E,I. CE I is not in the 00:09:20.850 --> 00:09:23.920 list, and that's my answer. 00:09:26.842 --> 00:09:27.816 Yes? 00:09:27.816 --> 00:09:32.686 AUDIENCE: [UNINTELLIGIBLE] once more, then you get 00:09:32.686 --> 00:09:34.634 another path that's equally short. 00:09:34.634 --> 00:09:36.095 So why is that not the correct answer? 00:09:39.010 --> 00:09:40.100 PROFESSOR: A slightly different algorithm might give 00:09:40.100 --> 00:09:41.350 me that solution. 00:09:43.350 --> 00:09:47.080 All that I'm tracing here, I'm trying to be consistent with 00:09:47.080 --> 00:09:49.980 the algorithm that we discussed last time. 00:09:49.980 --> 00:09:52.350 But that's a very good point. 00:09:52.350 --> 00:09:56.750 So the breadth-first search with dynamic programming is 00:09:56.750 --> 00:09:59.510 guaranteed to give you a solution 00:09:59.510 --> 00:10:02.450 that has minimum length. 00:10:02.450 --> 00:10:07.040 It's not guaranteed to give you a particular solution of 00:10:07.040 --> 00:10:07.620 minimum length. 00:10:07.620 --> 00:10:10.450 So when there exists multiple solutions with the same 00:10:10.450 --> 00:10:14.230 length, this search algorithm might to give you any of them, 00:10:14.230 --> 00:10:15.780 and that's an important thing to keep in mind. 00:10:20.130 --> 00:10:23.170 So with regard to the problem, I'm trying to think ahead. 00:10:23.170 --> 00:10:25.900 I'm trying to think ahead to where this C is off the map, 00:10:25.900 --> 00:10:27.150 it's over here someplace. 00:10:29.550 --> 00:10:33.730 So what I want to do is stop thinking about how many hops 00:10:33.730 --> 00:10:36.460 there were and start thinking about how 00:10:36.460 --> 00:10:39.330 many miles there are. 00:10:39.330 --> 00:10:43.670 The first thing I want you to notice is that this search 00:10:43.670 --> 00:10:49.500 pattern that we did created a visitation list. 00:10:49.500 --> 00:10:51.940 We visited the states in the order of 00:10:51.940 --> 00:10:55.400 increasing number of hops. 00:10:55.400 --> 00:10:58.230 That's obviously a good thing. 00:10:58.230 --> 00:11:01.890 If we can always keep in the agenda the smallest number of 00:11:01.890 --> 00:11:07.570 hops to the next place, and if we faithfully visit states 00:11:07.570 --> 00:11:10.600 starting at the minimum number and proceeding up, so we 00:11:10.600 --> 00:11:13.440 started with A, there's no hops in getting to 00:11:13.440 --> 00:11:15.510 A, so that's 0. 00:11:15.510 --> 00:11:18.930 In going from A to B, there's 1 hop. 00:11:18.930 --> 00:11:20.850 In going from A to D there's 1 hop. 00:11:20.850 --> 00:11:24.445 In going from A to B to C, ABC, there's 2 hops. 00:11:27.050 --> 00:11:31.050 So what the algorithm that we described last time-- 00:11:31.050 --> 00:11:33.250 breadth-first with than dynamic programming does-- 00:11:33.250 --> 00:11:37.150 is it visits the states in the order of 00:11:37.150 --> 00:11:38.450 increasing number of hops. 00:11:38.450 --> 00:11:41.990 That's obviously a good thing. 00:11:41.990 --> 00:11:44.890 OK so what's my next slide? 00:11:44.890 --> 00:11:49.350 I want to think about C being off the map. 00:11:49.350 --> 00:11:53.930 So what I'd like to do is think about what order would 00:11:53.930 --> 00:11:58.853 this algorithm visit number of miles? 00:11:58.853 --> 00:12:03.580 So If I think about replacing the metric in the bottom with 00:12:03.580 --> 00:12:07.710 the number of miles, whenever the different actions that can 00:12:07.710 --> 00:12:12.150 occur incur different costs. 00:12:12.150 --> 00:12:13.190 Think about what I'm saying. 00:12:13.190 --> 00:12:15.530 So I'm saying that if I were at B and I think about my 00:12:15.530 --> 00:12:23.280 children ACE, which action I take, go from B to A or go 00:12:23.280 --> 00:12:27.760 from B to C are go from B to A, which action I take incurs 00:12:27.760 --> 00:12:31.010 different cost. 00:12:31.010 --> 00:12:35.320 So what I want to do now is think about, change the focus 00:12:35.320 --> 00:12:38.070 from thinking about how many hops is it to thinking about 00:12:38.070 --> 00:12:41.350 how many miles is it. 00:12:41.350 --> 00:12:43.930 So now, if I replace the metric-- 00:12:43.930 --> 00:12:47.610 so over here, the metric was how many hops, replace how 00:12:47.610 --> 00:12:51.050 many hops with how many miles-- 00:12:51.050 --> 00:12:55.330 and what you see is that the algorithm is not picking up. 00:12:55.330 --> 00:12:59.930 It's not visiting the states in order of 00:12:59.930 --> 00:13:02.410 increasing path length. 00:13:02.410 --> 00:13:04.130 That's what's wrong. 00:13:04.130 --> 00:13:09.890 So what we'd like to do is modify the algorithm somehow 00:13:09.890 --> 00:13:16.640 so that it proceeds through the paths shortest to longest. 00:13:16.640 --> 00:13:19.390 So that's the goal. 00:13:19.390 --> 00:13:21.600 And that's pretty easy to do. 00:13:21.600 --> 00:13:25.970 The first thing we have to do is put that new information 00:13:25.970 --> 00:13:30.290 somewhere, and I've already alluded to the fact that the 00:13:30.290 --> 00:13:32.440 way to think about the new information is that it's 00:13:32.440 --> 00:13:35.120 associated with actions. 00:13:35.120 --> 00:13:37.530 It's not associated with states. 00:13:37.530 --> 00:13:45.250 States are where we go to in the diagram, like state E. The 00:13:45.250 --> 00:13:49.040 extra cost is not summarized in the state, the extra cost 00:13:49.040 --> 00:13:53.880 is summarized in the exact path that we took. 00:13:53.880 --> 00:13:56.900 And the way we'll think about that is incrementally. 00:13:56.900 --> 00:14:01.750 So we create the past by doing actions and each action has a 00:14:01.750 --> 00:14:02.670 different cost. 00:14:02.670 --> 00:14:06.060 So the first thing we do is associate this additional cost 00:14:06.060 --> 00:14:08.880 with the actions. 00:14:08.880 --> 00:14:14.110 Then we are looking for a search procedure that will 00:14:14.110 --> 00:14:17.780 enumerate the paths in the order of path cost. 00:14:17.780 --> 00:14:21.400 And the way to do that is to think about the basic ordering 00:14:21.400 --> 00:14:27.340 schemes that we had before, which were the stack, last in, 00:14:27.340 --> 00:14:32.390 first out versus the queue, first in, first out. 00:14:32.390 --> 00:14:34.550 What we'll do is we'll make a trivial modification to the 00:14:34.550 --> 00:14:38.580 idea of a queue and we'll call it a priority queue. 00:14:38.580 --> 00:14:43.580 So a priority queue is basically like a queue, except 00:14:43.580 --> 00:14:47.360 the things that are queued have priorities. 00:14:47.360 --> 00:14:53.250 So the idea will be that when you push at possible action, 00:14:53.250 --> 00:14:56.350 say I had actions A,B, or C -- 00:14:56.350 --> 00:14:59.510 in addition to pushing them onto the queue, which is how 00:14:59.510 --> 00:15:03.750 we would have done breadth-first search, in 00:15:03.750 --> 00:15:06.460 addition to pushing them on the queue, I'll also associate 00:15:06.460 --> 00:15:09.190 with them a cost. 00:15:09.190 --> 00:15:13.650 So when I push A on the queue, the priority queue, I'll 00:15:13.650 --> 00:15:16.070 associate with that a cost, which I've arbitrarily said 00:15:16.070 --> 00:15:19.960 here, the cost is 3. 00:15:19.960 --> 00:15:22.620 When I push B, I'll associate a cost 6. 00:15:22.620 --> 00:15:26.090 When I push C, I'll associate a cost 1 so that when I do the 00:15:26.090 --> 00:15:29.990 first pop, what will come out will be the element that I 00:15:29.990 --> 00:15:35.540 pushed that has the smallest associated cost. 00:15:35.540 --> 00:15:39.600 That'll be a way that I can order then my search through 00:15:39.600 --> 00:15:43.350 the search tree in terms of the minimum costs. 00:15:43.350 --> 00:15:46.170 Is that clear? 00:15:46.170 --> 00:15:49.120 So the first time I do a pop, the element that pops out is 00:15:49.120 --> 00:15:51.723 the one with the least cost, which is this one, so I get C. 00:15:51.723 --> 00:15:58.000 C is then removed from the list and the second time I do 00:15:58.000 --> 00:16:01.810 it, when I do a pop, I pick out the one with the cost 3 00:16:01.810 --> 00:16:07.880 which is A. That's an easy modification to the schemes 00:16:07.880 --> 00:16:08.740 that we used before. 00:16:08.740 --> 00:16:11.300 Just like before, we can implement a priority queue 00:16:11.300 --> 00:16:13.320 with a list. 00:16:13.320 --> 00:16:18.020 Here we've put all the complication into popping. 00:16:18.020 --> 00:16:22.540 So we just push like we did before, just jam it in. 00:16:22.540 --> 00:16:24.750 So just add it to the end of the list. 00:16:24.750 --> 00:16:28.830 And we put the complication into pop, pop looks through 00:16:28.830 --> 00:16:31.500 the list and finds the one that has the 00:16:31.500 --> 00:16:34.120 biggest negative cost. 00:16:34.120 --> 00:16:36.880 That's just because we've got a utility routine that gave us 00:16:36.880 --> 00:16:38.130 the biggest. 00:16:38.130 --> 00:16:39.990 We want the smallest. 00:16:39.990 --> 00:16:45.780 We know that the costs are non-negative, so we implement 00:16:45.780 --> 00:16:48.310 the find the smallest by calling the routine find the 00:16:48.310 --> 00:16:50.695 biggest with a negative cost. 00:16:53.440 --> 00:16:57.110 So notice that all the new complication is in this pop 00:16:57.110 --> 00:16:59.460 routine, and if you think about it, pop is doing 00:16:59.460 --> 00:17:02.510 far too much work. 00:17:02.510 --> 00:17:06.609 The way this routine works, every time you do a pop, it 00:17:06.609 --> 00:17:08.349 goes through the whole list looking for 00:17:08.349 --> 00:17:10.660 something that is small. 00:17:10.660 --> 00:17:13.970 Obviously it ought to be able to keep track of progress that 00:17:13.970 --> 00:17:16.339 it's made in that previously. 00:17:16.339 --> 00:17:18.520 There are much better algorithms, but for the 00:17:18.520 --> 00:17:21.660 purpose of this illustration, we didn't bother with it. 00:17:21.660 --> 00:17:26.319 So this is not a very clever implementation. 00:17:26.319 --> 00:17:27.970 We're not trying to be clever, we're trying to 00:17:27.970 --> 00:17:30.450 illustrate the point. 00:17:30.450 --> 00:17:33.780 So if you were seriously try to do a big search, if you're 00:17:33.780 --> 00:17:37.950 writing code for Google, you would never do it this way. 00:17:37.950 --> 00:17:40.650 But the idea again is in abstraction. 00:17:40.650 --> 00:17:44.195 We're going to bury those details in the way the queue 00:17:44.195 --> 00:17:47.210 is implemented and then at the next higher level, we don't 00:17:47.210 --> 00:17:48.670 need to worry about those details. 00:17:48.670 --> 00:17:50.305 We'll abstract them away. 00:17:50.305 --> 00:17:53.680 Is that all clear? 00:17:53.680 --> 00:17:53.990 OK. 00:17:53.990 --> 00:17:57.560 So this then is the way we end up doing the search. 00:17:57.560 --> 00:18:03.340 So when we do the search, when we create a new node, the idea 00:18:03.340 --> 00:18:06.430 is going to be that we can generate a cost. 00:18:06.430 --> 00:18:11.470 Remember, nodes in the search tree summarize paths. 00:18:11.470 --> 00:18:13.300 Nodes are different from states, right? 00:18:13.300 --> 00:18:18.980 States are places that we can visit, nodes are paths. 00:18:18.980 --> 00:18:23.290 So the thing that we need to keep track of now in addition 00:18:23.290 --> 00:18:27.620 to what we did before, before we had the idea that nodes had 00:18:27.620 --> 00:18:30.470 states, they have a place where you are 00:18:30.470 --> 00:18:32.640 currently in the search. 00:18:32.640 --> 00:18:36.480 They have actions, which is which direction do you go next 00:18:36.480 --> 00:18:40.740 and they have parents and that was enough information to 00:18:40.740 --> 00:18:45.460 create and maintain a search tree. 00:18:45.460 --> 00:18:48.670 Now what we need to do is also keep track of cost. 00:18:48.670 --> 00:18:51.970 So we do that by adding instantiation time. 00:18:51.970 --> 00:18:55.210 When we create a new node, we have to also pass it what is 00:18:55.210 --> 00:18:57.470 the action cost. 00:18:57.470 --> 00:19:00.470 So in the previous example, the action cost would be the 00:19:00.470 --> 00:19:05.060 distance from B to C, for example, being 5, which is 00:19:05.060 --> 00:19:09.250 different from the distance between B to E, which is 1. 00:19:09.250 --> 00:19:13.330 So we have to associate at the time we create a node, what is 00:19:13.330 --> 00:19:16.620 the action cost associated with this new node. 00:19:16.620 --> 00:19:21.740 And then the node keeps track of the total path cost, so 00:19:21.740 --> 00:19:23.240 that's what the red stuff is doing. 00:19:23.240 --> 00:19:27.410 So it's a very small change to the code that we used for 00:19:27.410 --> 00:19:33.330 creating nodes in the previous two searches, and then we have 00:19:33.330 --> 00:19:37.040 to also change the way we do the basic search algorithm. 00:19:37.040 --> 00:19:40.120 And here too, the idea is pretty simple. 00:19:40.120 --> 00:19:43.310 It's almost exactly the same thing that we did before, with 00:19:43.310 --> 00:19:46.550 the idea that we substitute keep track of the agenda with 00:19:46.550 --> 00:19:51.800 a priority queue rather than with a queue or a stack. 00:19:51.800 --> 00:19:58.480 There's one more complication, and that is that in the past, 00:19:58.480 --> 00:20:03.360 we knew that all children added the same penalty. 00:20:03.360 --> 00:20:09.310 Because we only keeping track all of how many generations, 00:20:09.310 --> 00:20:15.140 how many hops are there to the current node, all children 00:20:15.140 --> 00:20:19.170 were in some sense created equal because we knew they all 00:20:19.170 --> 00:20:23.310 incurred one more hop. 00:20:23.310 --> 00:20:29.590 Here, because the children can have different associated 00:20:29.590 --> 00:20:36.850 action costs, we don't know at the time we've picked up the 00:20:36.850 --> 00:20:40.120 parent, we don't know at that time which child is going to 00:20:40.120 --> 00:20:42.930 end up being the shortest one. 00:20:42.930 --> 00:20:46.910 So previously, the goal test was performed when the 00:20:46.910 --> 00:20:49.360 children were pushed onto the agenda. 00:20:49.360 --> 00:20:55.220 Here we have to wait until we look at all of the children 00:20:55.220 --> 00:20:59.130 before we will know which child has the shortest length. 00:20:59.130 --> 00:21:02.050 And that just means that we take the goal test, which had 00:21:02.050 --> 00:21:06.260 been inside the 'for a in actions' loop. 00:21:06.260 --> 00:21:11.490 We have to factor that out and defer until the next time. 00:21:11.490 --> 00:21:13.330 So that's the only change to the algorithm 00:21:13.330 --> 00:21:16.680 that we need to make. 00:21:16.680 --> 00:21:17.880 So is that clear? 00:21:17.880 --> 00:21:21.980 So the idea is it's a pretty simple modification of the 00:21:21.980 --> 00:21:26.850 algorithm that we have so far, but it gives rise to a much 00:21:26.850 --> 00:21:28.340 more versatile kind of search. 00:21:32.950 --> 00:21:35.410 So last time we saw that there was really no good point for 00:21:35.410 --> 00:21:38.710 not doing the search, the breadth-first search with 00:21:38.710 --> 00:21:41.640 dynamic programming, we have the same thing here. 00:21:41.640 --> 00:21:47.270 So when you're doing the uniform costs search, there's 00:21:47.270 --> 00:21:50.150 no real good reason for not implementing that with dynamic 00:21:50.150 --> 00:21:52.590 programming, so we also want to think about the dynamic 00:21:52.590 --> 00:21:55.090 programming algorithm. 00:21:55.090 --> 00:21:57.440 So you remember in breadth-first search and in 00:21:57.440 --> 00:22:00.670 depth-first search, dynamic programming referred to the 00:22:00.670 --> 00:22:07.810 principle that the shortest path from X to Z through Y, so 00:22:07.810 --> 00:22:09.780 if you have a path from X to Z and you know it goes through 00:22:09.780 --> 00:22:13.210 Y, the shortest way you can get from X to Z through Y is 00:22:13.210 --> 00:22:16.200 to add the shortest path from X to Y to the shortest path 00:22:16.200 --> 00:22:18.030 from Y to Z. 00:22:18.030 --> 00:22:21.210 Sounds trivial, but it has a tremendous impact on the 00:22:21.210 --> 00:22:25.370 number of states that can be omitted from the search. 00:22:25.370 --> 00:22:28.470 Here, when we do the uniform cost search, we can do the 00:22:28.470 --> 00:22:31.540 same sort of thing but except that we run into the same sort 00:22:31.540 --> 00:22:36.600 of problem with not all paths from X to 00:22:36.600 --> 00:22:40.690 Y are created equally. 00:22:40.690 --> 00:22:43.820 We don't want to remember any random path from X to Y, we 00:22:43.820 --> 00:22:48.560 want to remember the best one, which means that in general, 00:22:48.560 --> 00:22:54.460 we're going to have to expand all of the children before 00:22:54.460 --> 00:23:00.210 we'll know which child gives the minimum length path. 00:23:00.210 --> 00:23:03.120 So that means that the dynamic programming principle that 00:23:03.120 --> 00:23:09.870 we'll use is to remember the state when it gets expanded, 00:23:09.870 --> 00:23:12.980 because it only gets expanded after its already being 00:23:12.980 --> 00:23:16.590 compared to its siblings. 00:23:16.590 --> 00:23:22.420 So wait until a state, wait until a path has been compared 00:23:22.420 --> 00:23:26.920 to all the siblings of that particular path before you 00:23:26.920 --> 00:23:28.950 consider it for dynamic programming. 00:23:28.950 --> 00:23:32.040 So we'll do that by not keeping track of states as 00:23:32.040 --> 00:23:35.520 they are visited, but instead keeping track of states as 00:23:35.520 --> 00:23:36.450 they are expanded. 00:23:36.450 --> 00:23:39.150 That's the same idea that we had to do when we had to 00:23:39.150 --> 00:23:41.770 reorder goal test. 00:23:41.770 --> 00:23:45.360 Defer the goal task until after you think 00:23:45.360 --> 00:23:47.800 about all the children. 00:23:47.800 --> 00:23:53.010 Defer putting it in the dynamic programming list until 00:23:53.010 --> 00:23:55.690 after you've looked at all the children and so that means 00:23:55.690 --> 00:23:59.910 that we think about expansions instead of visits. 00:23:59.910 --> 00:24:01.080 And so that looks like this. 00:24:01.080 --> 00:24:09.540 So just like we took the goal test outside the action list, 00:24:09.540 --> 00:24:13.130 in the previous breadth-first search we did the test goal 00:24:13.130 --> 00:24:17.360 state in this loop, here we defer it until we've looked at 00:24:17.360 --> 00:24:21.600 all the children and fetched the parent. 00:24:21.600 --> 00:24:24.360 So we defer it into the higher loop, we take it out of this 00:24:24.360 --> 00:24:28.080 moving into this and similarly, we take the dynamic 00:24:28.080 --> 00:24:30.490 programming memory. 00:24:30.490 --> 00:24:34.230 We now call it expanded to remind ourselves that what 00:24:34.230 --> 00:24:38.130 we're doing is keeping track of states after they were 00:24:38.130 --> 00:24:42.280 expanded, not after they were visited. 00:24:42.280 --> 00:24:47.760 And updating it again, not when we look at the individual 00:24:47.760 --> 00:24:51.160 actions, but only after we've decided which 00:24:51.160 --> 00:24:55.330 trial is the winner. 00:24:55.330 --> 00:24:56.670 OK? 00:24:56.670 --> 00:24:57.990 That's probably confusing. 00:24:57.990 --> 00:25:01.080 That's not important at this point, because I've written an 00:25:01.080 --> 00:25:04.780 example and hopefully by thinking through the example, 00:25:04.780 --> 00:25:07.470 you'll be able to see what the code is supposed to be doing. 00:25:07.470 --> 00:25:10.860 And then a good exercise is to go through the example, which 00:25:10.860 --> 00:25:14.420 will be posted on the web with all the gory details, and make 00:25:14.420 --> 00:25:19.940 sure that you can match up the search-- 00:25:19.940 --> 00:25:21.880 the partial results of the search-- to the way the 00:25:21.880 --> 00:25:24.080 algorithm is written. 00:25:24.080 --> 00:25:26.680 OK? 00:25:26.680 --> 00:25:28.980 So now I want to do the problem of interest. 00:25:28.980 --> 00:25:33.660 Think about what if one of these nodes, one of the 00:25:33.660 --> 00:25:37.270 states, state C, is very distant 00:25:37.270 --> 00:25:39.270 relative to all the rest. 00:25:39.270 --> 00:25:43.720 How will the new search, the uniform cost search, work with 00:25:43.720 --> 00:25:44.760 this problem? 00:25:44.760 --> 00:25:49.520 So we do the same sort of thing we did before. 00:25:49.520 --> 00:25:52.450 Now we have an agenda to keep track of the nodes under 00:25:52.450 --> 00:25:54.960 consideration. 00:25:54.960 --> 00:25:57.240 We have a dynamic programming list that is going to be 00:25:57.240 --> 00:26:00.670 called expanded because we don't add to it until we 00:26:00.670 --> 00:26:03.480 expand states. 00:26:03.480 --> 00:26:06.100 It had previously been called visited. 00:26:06.100 --> 00:26:09.540 And we also keep track of the metric, 00:26:09.540 --> 00:26:12.000 which is the path costs. 00:26:12.000 --> 00:26:17.800 So if we start by putting node A on the agenda, its path cost 00:26:17.800 --> 00:26:20.070 is 0, because it doesn't cost anything to get there because 00:26:20.070 --> 00:26:22.350 that's where we started. 00:26:22.350 --> 00:26:25.670 And we haven't expanded anybody yet. 00:26:25.670 --> 00:26:27.490 So notice that the starting state is a little bit 00:26:27.490 --> 00:26:31.050 different here because we're keeping track of expanded. 00:26:31.050 --> 00:26:34.670 The expanded list started out with 0 elements in it. 00:26:34.670 --> 00:26:36.820 Previously where we were keeping track of visits, it 00:26:36.820 --> 00:26:41.590 started out knowing already what was going on with A. 00:26:41.590 --> 00:26:47.790 So now we expand A, think about A's children, B and D, 00:26:47.790 --> 00:26:52.870 put them on the agenda, and add A to the expanded list. 00:26:52.870 --> 00:26:55.520 We expanded A so it's time to add it to the dynamic 00:26:55.520 --> 00:26:58.570 programming list. 00:26:58.570 --> 00:27:04.340 Then also keep track of the costs of these paths. 00:27:04.340 --> 00:27:10.330 AB costs 1, AD costs 1. 00:27:10.330 --> 00:27:12.470 That's the end of the first pass. 00:27:12.470 --> 00:27:16.030 Now pop the first guy off the queue. 00:27:16.030 --> 00:27:19.190 Expand it, that means we're expanding the B state. 00:27:19.190 --> 00:27:22.390 We go from A to B, so we're going to expand B. B Has 00:27:22.390 --> 00:27:27.320 children A, C and E. A has already been expanded so we 00:27:27.320 --> 00:27:28.875 don't need to think about A anymore. 00:27:31.620 --> 00:27:35.700 C and E, so it was A, C and E, C and E have not been 00:27:35.700 --> 00:27:41.790 expanded, so I expand B to get these two and I associate 00:27:41.790 --> 00:27:45.890 their total path costs. 00:27:45.890 --> 00:27:52.600 So the path ABC, ABC has length 6 and the path 00:27:52.600 --> 00:27:54.225 ABE has length 2. 00:27:59.670 --> 00:28:05.100 Then I take the first one off the agenda again, that's AD. 00:28:05.100 --> 00:28:09.310 I expand AD, which is expanding D. Put that on the 00:28:09.310 --> 00:28:12.700 expanded list, on the dynamic programming was list. 00:28:12.700 --> 00:28:18.710 D has children A, E, G. A is already on the expanded list, 00:28:18.710 --> 00:28:25.470 so that means I have to worry about E and G. Those paths 00:28:25.470 --> 00:28:28.030 have length 2 and 2. 00:28:28.030 --> 00:28:32.470 That was the same so far as the previous search. 00:28:32.470 --> 00:28:35.410 Now I see something different. 00:28:35.410 --> 00:28:40.420 Because I'm using a priority queue, I skip ABC because 00:28:40.420 --> 00:28:44.610 that's just not the right one to do next. 00:28:44.610 --> 00:28:48.650 So ABC, I'm keeping track of with the priority queue. 00:28:48.650 --> 00:28:53.300 I know that that path is already length 6. 00:28:53.300 --> 00:28:58.110 It could end up being the optimum path, but at this 00:28:58.110 --> 00:28:59.890 phase of the search, it's not the one I 00:28:59.890 --> 00:29:01.730 should think of next. 00:29:01.730 --> 00:29:04.600 The one I should think of next is the shortest path. 00:29:04.600 --> 00:29:08.430 So what I'm trying to do is search the search tree in 00:29:08.430 --> 00:29:10.620 order of shortest path. 00:29:10.620 --> 00:29:16.380 So I skip the ABC because its path is long and the minimum 00:29:16.380 --> 00:29:19.370 length, so back up one. 00:29:19.370 --> 00:29:22.680 So in the priority queue idea, I want to extract from the 00:29:22.680 --> 00:29:27.430 queue the first item with the minimum length, so that's ABE. 00:29:30.240 --> 00:29:32.070 Everyone's with that? 00:29:32.070 --> 00:29:40.420 So then I want to expand E. E has children B, D, F, H. So B 00:29:40.420 --> 00:29:44.650 and D are here, F and H are not, so I add 00:29:44.650 --> 00:29:49.380 ABEFH to the agenda. 00:29:49.380 --> 00:29:50.830 Each of those have length 3. 00:29:53.400 --> 00:29:58.195 So what's the next guy out of the agenda? 00:29:58.195 --> 00:30:00.690 AUDIENCE: A and E. 00:30:00.690 --> 00:30:05.470 PROFESSOR: I need the first one with the smallest path, 00:30:05.470 --> 00:30:07.610 the smallest cost possible. 00:30:07.610 --> 00:30:11.910 The smallest cost possible is 2, so ADE is the next guy. 00:30:11.910 --> 00:30:15.870 So I expand ADE, but I've already expanded E. I Don't 00:30:15.870 --> 00:30:18.950 need to do anything. 00:30:18.950 --> 00:30:19.430 OK? 00:30:19.430 --> 00:30:23.950 The dynamic expansion list is keeping track of the nodes 00:30:23.950 --> 00:30:25.130 I've already expanded. 00:30:25.130 --> 00:30:29.730 I already did E, there's nothing new to be learned. 00:30:29.730 --> 00:30:32.130 So that doesn't do anything. 00:30:32.130 --> 00:30:36.900 So the next one is G. Well I didn't do G yet, so add it to 00:30:36.900 --> 00:30:38.200 the expanded list. 00:30:38.200 --> 00:30:42.510 G is shorter than D and H. D was already there, H was not, 00:30:42.510 --> 00:30:48.990 so add H. 00:30:48.990 --> 00:30:55.420 The next one is F. I haven't expanded F yet, so let's do F. 00:30:55.420 --> 00:31:04.090 So F's children are C, E, I. C is not there, E is there, I is 00:31:04.090 --> 00:31:05.570 not there, so I add those. 00:31:09.980 --> 00:31:16.060 So next is this guy, H. H wasn't expended, so I 00:31:16.060 --> 00:31:17.830 add H to the list. 00:31:17.830 --> 00:31:24.570 H's children are E, G, I. EG are already there, I is not, 00:31:24.570 --> 00:31:25.820 so I add that. 00:31:28.180 --> 00:31:31.720 Try expanding H, but already did expand H so 00:31:31.720 --> 00:31:32.970 that doesn't count. 00:31:35.440 --> 00:31:38.460 Try expanding C, that's fine. 00:31:38.460 --> 00:31:42.090 Expand C, I haven't expanded C before, add it to the list. 00:31:42.090 --> 00:31:45.930 C's children are B and F. B and F are both there, didn't 00:31:45.930 --> 00:31:47.310 add any new children. 00:31:47.310 --> 00:31:50.551 AUDIENCE: Why'd you expand that C, why not H? 00:31:53.330 --> 00:31:55.040 PROFESSOR: Oh look at that, you're right. 00:31:55.040 --> 00:31:56.510 Oh, thank you very much. 00:31:56.510 --> 00:31:56.840 My slide is wrong. 00:31:56.840 --> 00:32:00.720 Ignore that, you're absolutely correct, thank you. 00:32:00.720 --> 00:32:03.760 So let's say I guess this proves that 200 people 00:32:03.760 --> 00:32:08.095 watching the lecturer have greater insight-- 00:32:08.095 --> 00:32:08.550 well anyway. 00:32:08.550 --> 00:32:09.790 Yes, that's wrong. 00:32:09.790 --> 00:32:12.410 Don't bother with that because it's got the wrong priority. 00:32:12.410 --> 00:32:15.110 Jump straight to that. 00:32:15.110 --> 00:32:17.480 I'll fix the slide on the web. 00:32:17.480 --> 00:32:18.520 You're absolutely right. 00:32:18.520 --> 00:32:21.450 I should have gone straight to there and when I tried to 00:32:21.450 --> 00:32:28.530 expand I, I realize that that's my answer, so I'm done. 00:32:28.530 --> 00:32:30.900 OK? 00:32:30.900 --> 00:32:32.900 Questions? 00:32:32.900 --> 00:32:34.170 OK it's a little tedious. 00:32:34.170 --> 00:32:39.550 The point is that it really wasn't very much different 00:32:39.550 --> 00:32:42.860 from doing breadth-first search. 00:32:42.860 --> 00:32:45.130 The same ideas still work. 00:32:45.130 --> 00:32:50.350 The same idea of organizing the search on a tree, looking 00:32:50.350 --> 00:32:53.360 for the minimum cost answer on a tree, 00:32:53.360 --> 00:32:54.330 that's the big picture. 00:32:54.330 --> 00:32:57.680 That's what we want you to know about. 00:32:57.680 --> 00:33:00.355 I mean, we may ask you a quiz question about breadth-first 00:33:00.355 --> 00:33:02.930 search or depth-first search or dynamic programming or 00:33:02.930 --> 00:33:05.410 whatever, but the big picture, the thing we really want you 00:33:05.410 --> 00:33:09.730 to know is how to think about a search. 00:33:09.730 --> 00:33:14.850 The way to think about a search is a sequence of states 00:33:14.850 --> 00:33:19.230 organized in a tree that you can then 00:33:19.230 --> 00:33:20.350 systematically search. 00:33:20.350 --> 00:33:23.870 That's the idea, and the point of going through the uniform 00:33:23.870 --> 00:33:30.540 cost search is to see first and foremost, that it fits the 00:33:30.540 --> 00:33:34.630 same structure, it's the same kind of problem. 00:33:34.630 --> 00:33:38.020 Secondly, there are very tiny details and so I've tried go 00:33:38.020 --> 00:33:38.900 over those details. 00:33:38.900 --> 00:33:41.860 The details have to do with keeping track of the action 00:33:41.860 --> 00:33:47.020 cost and keeping track of which one to do next by way of 00:33:47.020 --> 00:33:48.010 a priority queue. 00:33:48.010 --> 00:33:50.960 But the big picture is the same idea works. 00:33:50.960 --> 00:33:56.220 States, nodes, trees, search, cues. 00:33:56.220 --> 00:33:56.660 Questions? 00:33:56.660 --> 00:33:57.910 Comments? 00:34:00.300 --> 00:34:01.550 OK. 00:34:05.260 --> 00:34:08.570 The other important thing that I want to talk about today is 00:34:08.570 --> 00:34:12.139 again, this idea of trying to minimize the 00:34:12.139 --> 00:34:14.400 length of your search. 00:34:14.400 --> 00:34:16.750 The other point that you're supposed to get from these two 00:34:16.750 --> 00:34:20.560 lectures is depending on exactly how you set up the 00:34:20.560 --> 00:34:26.280 search, you can do a lot of work or less work. 00:34:26.280 --> 00:34:31.659 And we're always interested to do less, especially because if 00:34:31.659 --> 00:34:36.610 you can do a lot less, you can do a lot harder problem. 00:34:36.610 --> 00:34:45.360 So the other thing I want to talk about next is the idea 00:34:45.360 --> 00:34:53.130 that our searches so far have been starting state centric. 00:34:53.130 --> 00:34:54.540 What do I mean by that? 00:34:54.540 --> 00:34:59.330 Every search has a starting state and a goal, and the 00:34:59.330 --> 00:35:03.170 ordering of our searches so far have been go to the 00:35:03.170 --> 00:35:06.360 starting state, think of all the steps you can make from 00:35:06.360 --> 00:35:11.965 the starting state and just keep widening your search 00:35:11.965 --> 00:35:14.300 wider and wider and wider until you 00:35:14.300 --> 00:35:15.550 stumble onto the goal. 00:35:18.740 --> 00:35:20.810 OK, can you all see that that's what we've been doing? 00:35:20.810 --> 00:35:29.310 So nowhere in our code was the code aware of the goal other 00:35:29.310 --> 00:35:31.780 than am I there yet? 00:35:34.400 --> 00:35:37.900 So the search algorithm so far has been start at the 00:35:37.900 --> 00:35:43.100 beginning state, ask if I'm there yet, try the closest 00:35:43.100 --> 00:35:45.560 place I can go, am I there yet? 00:35:45.560 --> 00:35:46.570 Am I at the goal yet? 00:35:46.570 --> 00:35:50.920 Try the next closest place I can go from the start, am I at 00:35:50.920 --> 00:35:51.680 the goal yet? 00:35:51.680 --> 00:35:53.930 Try the next closest place I can start 00:35:53.930 --> 00:35:56.880 from, am I there yet? 00:35:56.880 --> 00:36:02.300 Everything has been starting state centric. 00:36:02.300 --> 00:36:05.530 Obviously, that's wrong. 00:36:05.530 --> 00:36:12.260 Somehow, when you do a search, if you were asked to find the 00:36:12.260 --> 00:36:17.640 shortest route through the interstate highway system from 00:36:17.640 --> 00:36:22.910 Kansas to Boston, there's a good chance you wouldn't be 00:36:22.910 --> 00:36:25.770 looking at Wyoming. 00:36:25.770 --> 00:36:26.980 Everybody knows enough geography to 00:36:26.980 --> 00:36:29.050 do that one, right? 00:36:29.050 --> 00:36:32.840 So the idea is that in the searches we've done so far, 00:36:32.840 --> 00:36:35.010 you would look at Wyoming before you'd look at 00:36:35.010 --> 00:36:36.420 Massachusetts. 00:36:36.420 --> 00:36:36.830 OK? 00:36:36.830 --> 00:36:38.610 That's stupid, right? 00:36:38.610 --> 00:36:40.810 Everybody sort of see that? 00:36:40.810 --> 00:36:44.160 So the searches we've done so far have been 00:36:44.160 --> 00:36:47.270 starting state centric. 00:36:47.270 --> 00:36:49.350 So what I'd like to do is think about 00:36:49.350 --> 00:36:51.510 a way to undo that. 00:36:51.510 --> 00:36:53.850 But again, to set things up, let's think about 00:36:53.850 --> 00:36:55.160 what I mean by that. 00:36:55.160 --> 00:36:59.720 Let's imagine a search very much like what we did before, 00:36:59.720 --> 00:37:05.060 except let's go from E to I, from Kansas to Boston, and I 00:37:05.060 --> 00:37:07.270 guess it's Kansas to Tallahassee, 00:37:07.270 --> 00:37:08.560 but you get the idea. 00:37:08.560 --> 00:37:11.900 So we start at E and let's think about 00:37:11.900 --> 00:37:13.530 how our search proceeds. 00:37:13.530 --> 00:37:19.560 So if you start at E, think about if we push E in the 00:37:19.560 --> 00:37:24.290 agenda, so I'm doing the uniform cost search with 00:37:24.290 --> 00:37:27.300 dynamic programing. 00:37:27.300 --> 00:37:30.640 I'm keeping track of the expanded state as my dynamic 00:37:30.640 --> 00:37:31.660 programming state. 00:37:31.660 --> 00:37:36.630 I'm starting at E. The cost of being at E is 0 because that's 00:37:36.630 --> 00:37:38.070 where I started. 00:37:38.070 --> 00:37:41.530 And now, I think about expanding E. So E goes on the 00:37:41.530 --> 00:37:42.780 expanded list. 00:37:44.910 --> 00:37:47.920 I think about all the children of E, the children are 00:37:47.920 --> 00:37:57.420 B,D,F,H. All of those children have distance 1, so when I 00:37:57.420 --> 00:38:00.590 look among them to figure out the next one that I should do, 00:38:00.590 --> 00:38:04.215 I do the first guy, EB. 00:38:04.215 --> 00:38:09.680 B's children are A and C, so I take off EB from the beginning 00:38:09.680 --> 00:38:10.930 of the agenda. 00:38:15.650 --> 00:38:18.620 Start again, B. B's children are A, C, E. 00:38:18.620 --> 00:38:20.670 E is already expanded. 00:38:20.670 --> 00:38:29.746 Push A and C. Pop D, D's children are A, E, G push A 00:38:29.746 --> 00:38:31.480 and G because E's already there. 00:38:34.120 --> 00:38:39.710 Expand F. F's children are C, E, I. E is 00:38:39.710 --> 00:38:42.860 already there, push CI. 00:38:42.860 --> 00:38:49.190 Expand H. H's children are G, I, E, G, I. E is already 00:38:49.190 --> 00:38:51.820 there, push GI. 00:38:51.820 --> 00:38:56.470 Expand A. A's children are B and D. They're already there, 00:38:56.470 --> 00:38:58.900 don't need to do anything. 00:38:58.900 --> 00:39:02.126 Expand C. C's children are BF. 00:39:02.126 --> 00:39:04.730 BF are there, I don't need to do anything. 00:39:04.730 --> 00:39:07.510 Expand A. BD are already there, I 00:39:07.510 --> 00:39:08.760 don't need to do anything. 00:39:08.760 --> 00:39:13.460 Expand G. G's children are DH, DH are both there, I don't 00:39:13.460 --> 00:39:14.450 need to do anything. 00:39:14.450 --> 00:39:17.890 Expand C. BF, BF nothing. 00:39:17.890 --> 00:39:20.300 Expand I, I'm there. 00:39:20.300 --> 00:39:20.680 Yes? 00:39:20.680 --> 00:39:24.552 AUDIENCE: Were you supposed adding ACE? 00:39:24.552 --> 00:39:27.940 PROFESSOR: Was I supposed to be adding AC? 00:39:27.940 --> 00:39:30.410 You add A when you expand it. 00:39:30.410 --> 00:39:32.470 Ah, yes, yes, yes. 00:39:32.470 --> 00:39:33.620 Thank you. 00:39:33.620 --> 00:39:35.800 I'll fix this one, too. 00:39:35.800 --> 00:39:40.070 So the question was when I expanded A, when I did this 00:39:40.070 --> 00:39:45.120 one for example, when I tried to expand A, I should have 00:39:45.120 --> 00:39:48.930 added it to the list here so I don't try to do it again. 00:39:48.930 --> 00:39:52.265 It wouldn't have affected the outcome, but I should have 00:39:52.265 --> 00:39:53.280 added it to that list. 00:39:53.280 --> 00:39:54.530 Thank you. 00:39:56.270 --> 00:39:56.700 Class -- 00:39:56.700 --> 00:39:58.430 2 Freeman -- 00:39:58.430 --> 00:39:58.710 0. 00:39:58.710 --> 00:39:59.250 Yes? 00:39:59.250 --> 00:40:05.510 AUDIENCE: What if you didn't expand it? 00:40:05.510 --> 00:40:08.135 I mean, do you consider it [UNINTELLIGIBLE] you 00:40:08.135 --> 00:40:09.385 should expand it? 00:40:11.510 --> 00:40:13.510 PROFESSOR: I'm sorry, I didn't hear the question. 00:40:13.510 --> 00:40:14.510 AUDIENCE: We didn't actually expand it. 00:40:14.510 --> 00:40:17.510 We considered expanding it, but then we noticed that. 00:40:17.510 --> 00:40:17.654 PROFESSOR: Correct, correct. 00:40:17.654 --> 00:40:19.640 So what I really should do is go back and read the code and 00:40:19.640 --> 00:40:22.950 figure out what I should do. 00:40:22.950 --> 00:40:26.370 What I'm trying to do is emulate the code. 00:40:26.370 --> 00:40:29.320 So your point is, it's a technical definition about 00:40:29.320 --> 00:40:31.040 whether I want to think about whether I actually 00:40:31.040 --> 00:40:32.910 expanded it or not. 00:40:32.910 --> 00:40:36.580 If I don't add any children, was it a real expansion? 00:40:36.580 --> 00:40:39.480 And that's a question that is determined by where was the if 00:40:39.480 --> 00:40:43.445 statement in the code, and frankly I don't remember. 00:40:46.630 --> 00:40:48.700 It does not expand it, ah I have the right answer. 00:40:48.700 --> 00:40:50.080 AUDIENCE: It does expand it. 00:40:50.080 --> 00:40:51.055 PROFESSOR: It does expand it. 00:40:51.055 --> 00:40:52.090 So I have the wrong answer. 00:40:52.090 --> 00:40:52.520 Class -- 00:40:52.520 --> 00:40:55.100 2 and a 1/2. 00:40:55.100 --> 00:41:04.360 OK so the point of this is that the search was symmetric 00:41:04.360 --> 00:41:07.350 around E, even though the goal is not. 00:41:11.140 --> 00:41:11.990 OK? 00:41:11.990 --> 00:41:16.390 And the question is, how could we fix it so the search is not 00:41:16.390 --> 00:41:20.190 symmetric around E -- the starting point. 00:41:20.190 --> 00:41:24.670 How do I fix it so the search is biased toward going toward 00:41:24.670 --> 00:41:25.920 the answer? 00:41:28.930 --> 00:41:31.920 And so the way we think about this is with something we 00:41:31.920 --> 00:41:34.650 called heuristics. 00:41:34.650 --> 00:41:39.370 So if you think about the searches we've been doing, 00:41:39.370 --> 00:41:42.170 either breadth-first or depth-first from last time 00:41:42.170 --> 00:41:49.720 where we counted the number of hops or today where we counted 00:41:49.720 --> 00:41:55.850 the lengths of paths, each of those considered what thing to 00:41:55.850 --> 00:42:01.620 do next based on the path from the starting point to the 00:42:01.620 --> 00:42:03.800 point under consideration. 00:42:03.800 --> 00:42:10.150 The idea of a heuristic is to add something that informs the 00:42:10.150 --> 00:42:15.730 search about how distance, how much distance we're expecting 00:42:15.730 --> 00:42:20.940 to add from the point under consideration to the goal. 00:42:20.940 --> 00:42:25.670 So the idea of the heuristic is to put in the second part 00:42:25.670 --> 00:42:26.920 of the path. 00:42:28.270 --> 00:42:32.710 The problem with a heuristic is that finding the second 00:42:32.710 --> 00:42:38.090 part of the path is just as hard as finding the first part 00:42:38.090 --> 00:42:45.240 of the path, and it would be a terrible idea to -- for every 00:42:45.240 --> 00:42:52.460 point in the search tree run a new search to find the best 00:42:52.460 --> 00:42:58.020 answer from that point to the goal -- 00:42:58.020 --> 00:43:02.090 because that would increase the length of the search time 00:43:02.090 --> 00:43:04.500 enormously. 00:43:04.500 --> 00:43:05.820 So it's a bad idea. 00:43:05.820 --> 00:43:09.790 So the problems are of equal complexity, the problem of 00:43:09.790 --> 00:43:14.350 getting from the start point to the place of interest and 00:43:14.350 --> 00:43:17.020 the problem of going from the place of interest to the goal 00:43:17.020 --> 00:43:19.500 are problems of equal complexity. 00:43:19.500 --> 00:43:23.220 We don't want to try to solve the problem of making the 00:43:23.220 --> 00:43:28.210 search better informed by increasing the complexity of 00:43:28.210 --> 00:43:30.900 the search drastically. 00:43:30.900 --> 00:43:32.280 So that's the issue. 00:43:32.280 --> 00:43:36.380 So a heuristic is going to be a way of approximating the 00:43:36.380 --> 00:43:40.780 amount of work we have to do yet, where what we would like 00:43:40.780 --> 00:43:45.380 it to be is not all that terribly difficult to compute. 00:43:45.380 --> 00:43:48.900 So one way we could think about that would be to 00:43:48.900 --> 00:43:52.960 consider as an approximation to how much work we have to 00:43:52.960 --> 00:43:58.760 do, the Manhattan distance for example, to complete the path. 00:43:58.760 --> 00:44:04.670 The Manhattan distance is the sum of the x and y distance. 00:44:04.670 --> 00:44:07.700 Generally speaking, Manhattan distance is not a good idea 00:44:07.700 --> 00:44:11.680 for map-like problems because generally you can cut across 00:44:11.680 --> 00:44:14.440 corners in such searches. 00:44:14.440 --> 00:44:17.620 In this particular search, since I've excluded cutting 00:44:17.620 --> 00:44:23.370 across diagonals, since the search space is already 00:44:23.370 --> 00:44:26.750 Manhattan, thinking about a heuristic that's based on 00:44:26.750 --> 00:44:29.232 Manhattan distance is probably OK. 00:44:32.280 --> 00:44:37.120 So the idea is to develop a heuristic and he what I'm 00:44:37.120 --> 00:44:41.980 going to think about is, what if I complete the path by 00:44:41.980 --> 00:44:46.100 adding the Manhattan distance from the point under 00:44:46.100 --> 00:44:48.150 consideration to the goal. 00:44:48.150 --> 00:44:53.000 OK, so now if I started at E like before and I'm going 00:44:53.000 --> 00:44:58.560 toward I like before, then I start with the agenda having 00:44:58.560 --> 00:45:01.350 just E and having expanded nothing. 00:45:04.890 --> 00:45:11.160 However, the cost associated with E is no longer 0. 00:45:11.160 --> 00:45:15.510 The cost of going from E, the starting point to E, the point 00:45:15.510 --> 00:45:20.410 under consideration is still 0, but I'm estimating the cost 00:45:20.410 --> 00:45:24.685 of going from E to I by the Manhattan distance between E 00:45:24.685 --> 00:45:27.410 and I, which is 2. 00:45:27.410 --> 00:45:30.120 The Manhattan distance between E and I is you have to 00:45:30.120 --> 00:45:34.370 increment x by 1 and you have to document y by 1. 00:45:34.370 --> 00:45:40.560 So instead of saying that the cost of state E is 0, I'm 00:45:40.560 --> 00:45:42.273 saying that it's 2. 00:45:42.273 --> 00:45:45.980 Is that clear why I'm doing that? 00:45:45.980 --> 00:45:51.140 So now I expand E, I think about the children B,D,F,H -- 00:45:51.140 --> 00:45:57.790 BDFH, and those children now are not the same cost. 00:45:57.790 --> 00:46:01.410 Even though it costs the same amount to go from E to each of 00:46:01.410 --> 00:46:06.580 its children, going from its children to the goal, going 00:46:06.580 --> 00:46:10.990 from each child to the goal does not cost the same amount. 00:46:10.990 --> 00:46:16.610 If I were to go from E to B, that's a cost of 1. 00:46:16.610 --> 00:46:22.090 But the Manhattan distance from B to I is 3. 00:46:22.090 --> 00:46:25.360 So I'm estimating, then, that the cost of making the 00:46:25.360 --> 00:46:31.030 decision go from E to B is 4. 00:46:31.030 --> 00:46:36.330 The real cost of going from E to B plus the estimated cost 00:46:36.330 --> 00:46:42.350 of going from B to I. Similarly, if I go from E to 00:46:42.350 --> 00:46:47.370 D, the Manhattan distance is 3, so that's a length 4. 00:46:47.370 --> 00:46:50.730 If I go from E to F, Manhattan distance from F to I is just 00:46:50.730 --> 00:46:54.910 1, so the total cost is just 2. 00:46:54.910 --> 00:47:00.250 So now rather than circling out from the starting point, 00:47:00.250 --> 00:47:04.890 my next step is biased toward the goal. 00:47:04.890 --> 00:47:09.700 So my next step is biased toward so the remaining items, 00:47:09.700 --> 00:47:13.400 the smallest cost is 2, so the next place 00:47:13.400 --> 00:47:17.430 that I expand is EF. 00:47:17.430 --> 00:47:22.880 F's children are C, E, I. E is already here, so I 00:47:22.880 --> 00:47:24.960 only think of CI. 00:47:24.960 --> 00:47:32.070 C and I also have different costs, So the cost of going 00:47:32.070 --> 00:47:39.630 EFC, EFC, the direct cost is 2 and the estimated distance, 00:47:39.630 --> 00:47:42.400 the Manhattan distance between C and I is also 2, so that's a 00:47:42.400 --> 00:47:48.530 cost 4 whereas the cost of EFI, EFI has a direct cost of 00:47:48.530 --> 00:47:54.300 2 and the Manhattan distance from I to I is 0. 00:47:54.300 --> 00:47:59.730 So now I look for the minimum distance that's remaining, so 00:47:59.730 --> 00:48:07.180 that's going to be H. I expand H, the children are E, G, I. 00:48:07.180 --> 00:48:08.560 So E is already here. 00:48:08.560 --> 00:48:10.000 I think about GI. 00:48:10.000 --> 00:48:12.286 Same sort of deal, some of them are short, some of them 00:48:12.286 --> 00:48:16.930 are long and as I proceed to the search, I very quickly 00:48:16.930 --> 00:48:22.810 find I without having ever looked in the wrong direction, 00:48:22.810 --> 00:48:25.180 or at least having looked minimally 00:48:25.180 --> 00:48:25.880 in the wrong direction. 00:48:25.880 --> 00:48:27.570 Is that clear? 00:48:27.570 --> 00:48:35.940 So the idea in a heuristic is to add an estimate of how much 00:48:35.940 --> 00:48:41.280 it will cost to complete the path so that you bias the 00:48:41.280 --> 00:48:44.040 search toward the goal. 00:48:44.040 --> 00:48:46.860 Rather than making circles that spiral out from the 00:48:46.860 --> 00:48:49.030 starting point, make the spirals 00:48:49.030 --> 00:48:52.090 biased toward the goal. 00:48:52.090 --> 00:48:53.450 And here's the way you do that. 00:48:53.450 --> 00:48:54.920 It's very easy. 00:48:54.920 --> 00:48:57.590 All you do is every place we would have looked at cost 00:48:57.590 --> 00:49:00.910 before, add the heuristic function. 00:49:00.910 --> 00:49:04.170 So you have to add a heuristic function, that's the part 00:49:04.170 --> 00:49:05.240 that's hard. 00:49:05.240 --> 00:49:08.780 The code, given the heuristic function, is easy. 00:49:08.780 --> 00:49:11.050 The really hard part is actually figuring out what a 00:49:11.050 --> 00:49:13.090 reasonable heuristic is. 00:49:13.090 --> 00:49:18.130 The reason that's hard is that you have to be careful not to 00:49:18.130 --> 00:49:21.050 miss the solution. 00:49:21.050 --> 00:49:25.700 So the heuristic function can't be bigger than the 00:49:25.700 --> 00:49:27.100 actual distance. 00:49:27.100 --> 00:49:28.260 OK, why is that? 00:49:28.260 --> 00:49:31.590 The agenda is trying to keep track of all the possible 00:49:31.590 --> 00:49:35.050 places that you could look next. 00:49:35.050 --> 00:49:40.230 If your heuristic function makes the next step look too 00:49:40.230 --> 00:49:46.160 big, it'll be taken out of the agenda and never appear again, 00:49:46.160 --> 00:49:49.540 and you'll never find that path. 00:49:49.540 --> 00:49:51.930 So when you're making a heuristic function, you have 00:49:51.930 --> 00:49:57.300 to be very careful not to ever overestimate the distance from 00:49:57.300 --> 00:50:00.930 where you are to the goal. 00:50:00.930 --> 00:50:04.920 If you ever overestimate it, then you can exclude forever 00:50:04.920 --> 00:50:10.090 more, so think about the agenda as a pruning operation. 00:50:10.090 --> 00:50:11.410 We did this starting last time. 00:50:11.410 --> 00:50:13.480 When we think about pruning, we pop off 00:50:13.480 --> 00:50:14.430 things from the agenda. 00:50:14.430 --> 00:50:15.130 We say -- 00:50:15.130 --> 00:50:17.050 don't ever need to look there, don't need to look there. 00:50:17.050 --> 00:50:18.300 We pruned it. 00:50:21.660 --> 00:50:24.980 If you have a heuristic that it is too big you can prune a 00:50:24.980 --> 00:50:28.970 path that was the answer. 00:50:28.970 --> 00:50:31.200 So you have to be careful never to do that. 00:50:31.200 --> 00:50:32.350 So it's asymmetrical. 00:50:32.350 --> 00:50:38.300 If you were to put in a heuristic that is too small, 00:50:38.300 --> 00:50:41.720 that causes you to underestimate the penalty of 00:50:41.720 --> 00:50:45.110 going in the wrong direction. 00:50:45.110 --> 00:50:49.750 So if you said, I'm trying to go from Kansas to Boston and 00:50:49.750 --> 00:50:52.740 you inadvertently said that Wyoming really didn't cost 00:50:52.740 --> 00:50:58.830 anything, then you would not necessarily exclude the 00:50:58.830 --> 00:51:03.590 correct answer, but you would include and cause the search 00:51:03.590 --> 00:51:07.140 to consider a necessary path. 00:51:07.140 --> 00:51:11.150 So the idea is that you would like the heuristic to be the 00:51:11.150 --> 00:51:16.300 same as the real cost or smaller. 00:51:16.300 --> 00:51:19.810 You don't want to end up solving another search problem 00:51:19.810 --> 00:51:22.680 in order to calculate it, because that will increase the 00:51:22.680 --> 00:51:25.000 cost of doing the search too much. 00:51:25.000 --> 00:51:30.280 So you would like some number that's easy to calculate that 00:51:30.280 --> 00:51:33.320 has the guarantee that it will always be less than or equal 00:51:33.320 --> 00:51:38.200 to the actual cost, and that's the art of doing a heuristic. 00:51:38.200 --> 00:51:41.610 If you satisfy those, then that previous algorithm that 00:51:41.610 --> 00:51:42.610 we looked at, which is -- 00:51:42.610 --> 00:51:44.920 in the literature it's call the A-Star Algorithm for 00:51:44.920 --> 00:51:46.710 historical reasons. 00:51:46.710 --> 00:51:50.640 That algorithm, if you obey these rules for finding 00:51:50.640 --> 00:51:54.010 admission an admissible heuristic, if you find an 00:51:54.010 --> 00:51:57.590 admissible heuristic, then the A-Star search will be a lot 00:51:57.590 --> 00:52:02.980 faster and still find a solution with the same length. 00:52:05.920 --> 00:52:08.920 OK, so now just to see if you're following what I'm 00:52:08.920 --> 00:52:12.160 saying, here's a question to ask yourself. 00:52:12.160 --> 00:52:13.380 Remember the tiles problem? 00:52:13.380 --> 00:52:17.110 The tiles problem is the first problem that I did last time. 00:52:17.110 --> 00:52:19.840 The idea was, imagine starting in this 00:52:19.840 --> 00:52:22.890 configuration 12345678. 00:52:22.890 --> 00:52:26.880 Move one tile at a time by moving the tile into the free 00:52:26.880 --> 00:52:30.740 spot, so I could move 8 to the right or 6 down. 00:52:30.740 --> 00:52:33.960 Keep doing that until you perturb this configuration 00:52:33.960 --> 00:52:35.210 into this configuration. 00:52:38.350 --> 00:52:42.230 We saw last time that there are a large number of states-- 00:52:42.230 --> 00:52:44.390 there's a third of a million states-- 00:52:44.390 --> 00:52:46.830 so this is a big search problem, even though it's 00:52:46.830 --> 00:52:48.170 something you've almost certainly 00:52:48.170 --> 00:52:49.625 also solved as a child. 00:52:49.625 --> 00:52:52.450 And in fact, my version, it was the same as yours, I'm 00:52:52.450 --> 00:52:54.420 sure, was a 4-by-4. 00:52:54.420 --> 00:52:57.170 I did the 15 puzzle, not the eight puzzle, but 00:52:57.170 --> 00:52:59.430 it's the same idea. 00:52:59.430 --> 00:53:04.340 So what I want to do is consider heuristics. 00:53:04.340 --> 00:53:05.910 Consider three heuristics. 00:53:05.910 --> 00:53:08.730 Heuristic A is 0. 00:53:08.730 --> 00:53:10.850 It always returns 0. 00:53:10.850 --> 00:53:14.530 That's an easy heuristic to calculate, right? 00:53:14.530 --> 00:53:18.000 Heuristic B is sum the number of tiles that are 00:53:18.000 --> 00:53:21.220 in the wrong position. 00:53:21.220 --> 00:53:23.960 What is heuristic B for this state? 00:53:23.960 --> 00:53:25.210 AUDIENCE: 8? 00:53:28.820 --> 00:53:30.910 PROFESSOR: 8 -- there's 8 tiles 00:53:30.910 --> 00:53:33.950 that are out of position. 00:53:33.950 --> 00:53:40.360 So heuristic C is the sum of the Manhattan Distances 00:53:40.360 --> 00:53:51.040 required to move each title to their respective locations and 00:53:51.040 --> 00:53:54.190 then calculate two partial sums. 00:53:54.190 --> 00:53:57.480 Consider MI to be the number of moves and the best solution 00:53:57.480 --> 00:54:00.800 if you use heuristic I and EI is the number of states that 00:54:00.800 --> 00:54:04.410 are expanded while you're doing the search. 00:54:04.410 --> 00:54:08.150 If you use heuristic I, which of the following 00:54:08.150 --> 00:54:10.890 statements are true? 00:54:10.890 --> 00:54:15.090 OK, take a minute, talk to your neighbor, figure it out 00:54:15.090 --> 00:54:17.196 which of these are true. 00:54:17.196 --> 00:57:32.480 [CLASS TALKING] 00:57:32.480 --> 00:57:34.860 PROFESSOR: OK so what's the smallest 00:57:34.860 --> 00:57:38.090 numbered correct answer? 00:57:43.608 --> 00:57:46.584 The smallest numbered correct answer. 00:57:46.584 --> 00:57:48.072 Oh, come on. 00:57:48.072 --> 00:57:49.064 Volunteer. 00:57:49.064 --> 00:57:50.056 Explain it with your neighbor. 00:57:50.056 --> 00:57:51.550 OK, very good. 00:57:51.550 --> 00:57:54.540 The smallest numbered correct answer is (1). 00:57:54.540 --> 00:57:56.700 MA equals MB equals MC. 00:57:56.700 --> 00:57:59.545 Why is that? 00:57:59.545 --> 00:58:04.515 How can I prove that MA equals MB equals MC. 00:58:04.515 --> 00:58:07.497 What do I have to do? 00:58:07.497 --> 00:58:07.994 Yes? 00:58:07.994 --> 00:58:10.976 AUDIENCE: You'll have to reach the 00:58:10.976 --> 00:58:12.467 shortest possible solution. 00:58:12.467 --> 00:58:14.810 PROFESSOR: So under what conditions will they all reach 00:58:14.810 --> 00:58:16.443 the same length solution? 00:58:16.443 --> 00:58:19.425 AUDIENCE: They're all doing backflips. 00:58:19.425 --> 00:58:21.413 PROFESSOR: They're all doing backflips. 00:58:21.413 --> 00:58:23.401 There's another condition. 00:58:23.401 --> 00:58:24.395 Yes? 00:58:24.395 --> 00:58:27.430 AUDIENCE: That they're all either exactly [INAUDIBLE]. 00:58:27.430 --> 00:58:32.460 PROFESSOR: So the heuristics, all three heuristics have to 00:58:32.460 --> 00:58:37.630 be admissible, which means that they have to be 00:58:37.630 --> 00:58:39.830 non-negative numbers. 00:58:39.830 --> 00:58:43.520 To be admissible, a heuristic has to be non-negative. 00:58:43.520 --> 00:58:46.580 And it has to generate an answer that's smaller than the 00:58:46.580 --> 00:58:50.310 actual number of moves necessary to 00:58:50.310 --> 00:58:52.270 complete the path. 00:58:52.270 --> 00:58:54.950 So we have to prove that these are all admissible. 00:58:58.400 --> 00:59:00.830 So, are they all non-negative? 00:59:00.830 --> 00:59:02.220 Yes. 00:59:02.220 --> 00:59:06.900 Are they all less than or equal to the number? 00:59:06.900 --> 00:59:08.880 So let's do that. 00:59:08.880 --> 00:59:10.170 Let's first of all get an answer. 00:59:10.170 --> 00:59:12.080 So we'll do that after we do the second part. 00:59:12.080 --> 00:59:14.650 What's the second smallest correct statement? 00:59:18.514 --> 00:59:22.378 Let me see if I can answer it, yes? 00:59:22.378 --> 00:59:24.690 OK, the answer is 4. 00:59:24.690 --> 00:59:26.110 So, how do you know that EA is bigger than EB 00:59:26.110 --> 00:59:27.360 is bigger than EC? 00:59:30.090 --> 00:59:32.850 So the number of states expanded has to do with the 00:59:32.850 --> 00:59:35.800 size of the heuristic. 00:59:35.800 --> 00:59:39.150 If the size of the heuristic is 0, that's the same as not 00:59:39.150 --> 00:59:39.840 using a heuristic. 00:59:39.840 --> 00:59:43.120 That will search all possible states in a breadth-first 00:59:43.120 --> 00:59:44.880 search fashion. 00:59:44.880 --> 00:59:49.630 If the heuristic is anything that's bigger, the number of 00:59:49.630 --> 00:59:52.240 searches will go down. 00:59:52.240 --> 00:59:55.570 What's the greater than or equal to thing doing here? 00:59:55.570 --> 00:59:56.067 Yes? 00:59:56.067 --> 00:59:58.055 AUDIENCE: Number (3) is technically also true, because 00:59:58.055 --> 01:00:00.540 if (1) is true, then (3) has to be true. 01:00:00.540 --> 01:00:03.025 PROFESSOR: If the number (3) is technically 01:00:03.025 --> 01:00:10.500 the number M. [LAUGHTER] 01:00:10.500 --> 01:00:12.246 OK, OK, OK. 01:00:12.246 --> 01:00:15.210 [APPLAUSE] 01:00:15.210 --> 01:00:19.070 OK, class, three plus. 01:00:19.070 --> 01:00:24.240 Freeman, oh well. 01:00:24.240 --> 01:00:25.080 Yes, you're right. 01:00:25.080 --> 01:00:26.810 Yes, I agree. 01:00:26.810 --> 01:00:28.060 Did you raise your hand for (3)? 01:00:31.120 --> 01:00:35.380 So (3) is technically the second, yes that's right, 01:00:35.380 --> 01:00:36.990 that's right. 01:00:36.990 --> 01:00:40.920 OK so moving on. 01:00:40.920 --> 01:00:42.150 Number (5) -- 01:00:42.150 --> 01:00:44.570 the same best solution will result for all 01:00:44.570 --> 01:00:45.310 the heuristics -- 01:00:45.310 --> 01:00:46.560 true or false? 01:00:56.100 --> 01:00:59.170 Come on, things can only go downhill for me. 01:00:59.170 --> 01:01:04.290 So the same best solution will result for all of the 01:01:04.290 --> 01:01:05.540 heuristics? 01:01:08.790 --> 01:01:11.260 How could it possibly be false? 01:01:11.260 --> 01:01:11.570 Right? 01:01:11.570 --> 01:01:14.562 Didn't we already said MA was equal to MB equals MC. 01:01:22.434 --> 01:01:23.910 Yeah? 01:01:23.910 --> 01:01:24.852 AUDIENCE: It's the same amount of moves, but maybe not 01:01:24.852 --> 01:01:25.300 exactly the same solutions. 01:01:25.300 --> 01:01:31.340 So if there are multiple solutions of the same length, 01:01:31.340 --> 01:01:33.930 the difference heuristics don't have to give you the 01:01:33.930 --> 01:01:36.580 same solution exactly. 01:01:36.580 --> 01:01:38.420 They have to give you solutions 01:01:38.420 --> 01:01:39.670 with the same length. 01:01:42.180 --> 01:01:45.490 So what happens with the heuristics is you perturb the 01:01:45.490 --> 01:01:47.560 order of search. 01:01:47.560 --> 01:01:50.480 If you perturb the order of search, the only thing that is 01:01:50.480 --> 01:01:54.260 proved is that you get a minimum length solution, not 01:01:54.260 --> 01:01:56.560 the same minimum length solution. 01:01:56.560 --> 01:01:58.890 This particular problem has lots of solutions and so you 01:01:58.890 --> 01:02:01.330 don't necessarily get the same solution when you use 01:02:01.330 --> 01:02:05.870 different heuristics, OK? 01:02:05.870 --> 01:02:11.620 So the final point is that the addition of the heuristics can 01:02:11.620 --> 01:02:13.830 be extremely effective. 01:02:13.830 --> 01:02:20.760 If you run this problem with our search algorithm, you 01:02:20.760 --> 01:02:24.750 always get solutions with 22 moves in them. 01:02:24.750 --> 01:02:27.770 That's good because all the heuristics were admissible so 01:02:27.770 --> 01:02:33.390 you always get a right answer -- a shortest answer. 01:02:33.390 --> 01:02:36.640 But the number of visited and expanded are drastically 01:02:36.640 --> 01:02:41.200 different when you add the heuristics. 01:02:41.200 --> 01:02:47.150 So if you use here heuristic A, which is equivalent to no 01:02:47.150 --> 01:02:53.800 heuristic, you end up visiting 170,000 states to find this 01:02:53.800 --> 01:02:57.020 answer, where if you used the Manhattan distance to the 01:02:57.020 --> 01:03:01.190 goal, the sum of the Manhattan distances, you do a very small 01:03:01.190 --> 01:03:02.300 fraction of that. 01:03:02.300 --> 01:03:05.650 So the point is that this stuff matters, especially when 01:03:05.650 --> 01:03:08.860 you do a higher-dimension search, which is all of the 01:03:08.860 --> 01:03:11.290 searches that we'll will be interested in. 01:03:11.290 --> 01:03:15.970 So the idea is that the order really does matter and with 01:03:15.970 --> 01:03:20.750 that, I'll conclude with a reminder that tomorrow evening 01:03:20.750 --> 01:03:23.830 is the makeup/retake day for Nano Quizzes. 01:03:23.830 --> 01:03:25.760 Please come to the lab if you'd like to make up or 01:03:25.760 --> 01:03:27.010 retake the Nano Quiz.