Permalink
Browse files

Transcribed some more

  • Loading branch information...
1 parent df74823 commit a94647668084eb32d2254a5cf378a99e1ea4acc3 @anyu anyu committed Mar 1, 2012
Showing with 22 additions and 1 deletion.
  1. +22 −1 transcript.md
View
@@ -42,4 +42,25 @@ The original content was licensed under CC-BY (http://creativecommons.org/licens
[[14:26]] So, creators need to be able to see what they're doing. If you're designing something embedded in time you need to be able to control time. You need to be able to see across time, otherwise you're flying blind.
-[[14:40]] As I was playing with this, I noticed it's fun to play with gravity.
+[[14:40]] As I was playing with this, I noticed it's fun to play with gravity. So I can make gravity a little negative and he starts to float up in the air. [laughter] And I can kind of play with that and try to get him to stay there. And you could probably make an entire game around just the mechanic here - gravity manipulation. In fact, I bet I could fiddle with any part of this code and come up with an idea for a game. Even if I just comment out the first statement in the code, now my guy can't move left - he can only move right. Which sounds kinda silly, but Terry Cavanagh actually made a beautiful game around that concept called "Don't Look Back". Terry Cavanagh, he made another really wonderful game which you might have seen, called "V", spelled as the letter v six times. And, the way that game works, is that you can't jump. Instead, you can only flip upside down, and you fall up instead of falling down. So it kinda works like this. You can walk on the ceiling or you can walk around on the ground. And so you have these levels which kinda look like this, and you kinda walk around...You have to learn how to navigate a terrain like this. And so if you had like a, something like that, you wouldn't be able to jump over it. You'd have to flip over and flip over; he got an amazing amount of game play out of this concept.
+
+[[16:07]] So again, being able to try ideas as you think of them. [pause] This example, and the last one with the tree, these are both very visual programs; they're able to see our changes just by seeing how the picture changes. So I was thinking about, how we could do more abstract coding that's more in line with this principle. How can we write a generic algorithm in such a way that we can see what we're doing. So as an example, let's take a look at binary search. Super quick refresher on how binary search works: you have an array of values that are in order, and you have a key, which is the value you're trying to locate within the array. And you keep track of two variables, which are the lower and upper bounds of where you think that value could possibly be; right now, it could be anywhere. And you look right in the middle of that range - if what you find is too small, then the key has to be after that. Look in the middle of the range, if what you find is too big, the key has to be before that. And you kinda keep subdividing your range until you narrow in on the value you're looking for. And in code, binary search looks like this. And from my perspective, you can't see anything here. You can't see anything. I see the word 'array', but I don't actually see an array. And so in order to write code like this, you have to imagine an array in your head, and you essentially have to play computer. You have to simulate in your head what each line of code would do on a computer. And to a large extent, the people that we consider to be skilled software engineers are just those people that are really good at playing computer. But if we're writing our code on a computer...why are we simulating what a computer would do in our head? Why doesn't the computer just do it...and show us?
+
+[[18:06]] So. Let's write binary search. Function "binary search" takes a key and an array. And then over here on this side, it's saying "Ok, it takes a key and an array, such as what? Give me an example; I need something to work with here." So, for instance, my array might be 'a', 'b', 'c', 'd', 'e', 'f'. And let's say for instance we're looking for the 'd'. So now let's start coding. The lower bound starts out as zero. Over here it says 'low equals zero', nothing amazing there. Upper bound starts out at the end of the array, so high equals array length minus one. And over here, it says 'high equals five'. So I have my abstract formula in the code. Over here, it's giving me the concrete value corresponding to these example arguments. So I don't have to maintain this picture in my head; it's just showing it to me.
+
+[[19:09]] So now I need the index in the middle of the array, so I'm going to take the average of those two. Mid equals low plus high over two, and...well that's obviously not right. Two point five is not a valid array index. So I guess I need to round this off. So I'm going to add the floor function and it rounded it down to two. And I caught that bug literally the second I typed it, instead of writing the function in twenty unit tests. So now I get the value out of the array...and then I need to subdivide my range, which, so this if statement which I'll just paste in here. So in this case, the value I found is less than the key, so it's taking this first branch of the if statement. This is adjusting the lower bound. Of course if the key was smaller, then it would take this branch of the if statement and adjust the upper bound. Or, if the key was 'c', then we would've just happened to find it on the first shot, and we'd return the index.
+
+[[20:14]] So this is the first iteration of this algorithm. And now what we need to do, is loop. We've subdivided the array, we need to keep subdividing until we narrow in on what we're looking for. So, we need to loop; I will just loop. While 1, do all this. And now what we have are three columns corresponding to three iterations of this loop. So this first column here is exactly what you saw before. Low and high span the entire array, we found a 'c', it was too low, so we adjusted our lower bound, ad loop up to here. Second iteration, bounds are tighter; we found an 'e'. Adjust the upper bound. Third iteration, loop up to here; low and high are the same. We've narrowed it down to a single candidate - it's indeed the key we're looking for, and we returned this index. So there's nothing hidden here; you see exactly what the algorithm is doing at every point. And I can go up to here and try different keys, so I can see how the algorithm behaves for these different input arguments.
+
+[[21:20]] And by looking across this data, I can develop an intuition for how this algorithm works. So I'm trying different keys here, and say I try looking for a 'g'. And this looks a little different. It's not actually returning. And the reason for this is, I'm looking for a key which is not actually in the array. And the only way of breaking out of this loop, is by finding the key. So it's kinda stuck here looping forever. So we can take a look at this and see what went wrong, where's the algorithm going off the rails. These first few iterations look fine, but this iteration looks weird, because low is greater than high. Our range is completely collapsed. So if we get to this point, then we know the key can't be found. So I see this faulty condition, and I say, "Oh, that's not right; low has to be less than or equal to high." Okay, well, I'll just put that over as the condition for my while statement. Low, less than equal to high, and then that would break out of the loop, and I would return some signal to say that it couldn't be found. So here we have three iterations of the loop, couldn't be found, we return a not found value.
+
+[[22:33]] So that's what it might be like to write an algorithm without a blindfold on. [applause]
+
+
+
+
+
+
+
+
+

0 comments on commit a946476

Please sign in to comment.