Okay. As we start doing these classroom discussion questions with repeat until loops, the amount of effort and thought that students have to put into analyzing things goes higher. It's really important that, yeah, we get them to do some challenging things, but you also have to be wary of making things so hard that they just look at it and they look up at the screen they go, "I don't even want to bother to think about that." So, one of the tricks I use is, I try to use some code that's really similar or identical to code that they have already worked with, so that they have a little bit of familiarity going into it. So, this one was taken from the helicopter example about height and takeoff height. But I might have changed things a little bit. Well, in fact I just changed one thing. So, first thing here, are these two, do these two programs do the exact same thing? By the way, it's really important that they don't always be true and not always be false. The answer here is true. So, again, we can look at the code in detail and it might be good to review with students. You set the takeoff height to a random number. We don't even see here where height is being set, because that's hidden away, but it doesn't really matter. The question is, is the expression height greater than takeoff height the same as takeoff height less than height? Now, students will be thinking about, especially those who've done a lot of less than or [inaudible] the other math thing, they're going to start over thinking and start going, "No. If it's greater than changes to less than, it's supposed to be less than or equal to." That's all there. So, it's good to get them doing this. We don't really care, we ought to make sure that students understand, it's not about memorizing whether these are the same or not, it's about can we figure it out. So, I use this as an excuse to tell students, "Well, how would we do it?" We shouldn't just look at it in the abstract, we should look at exact examples and then see if we can convince ourselves with a few examples that that holds for all. So, encourage them to set up a table with each of the variables that were being used here, height and takeoff height. Then, to copy in the two different expressions that we are comparing. The first one was, is height greater than takeoff height, and the second one is, is takeoff height less than height? So, you could pick any numbers but don't, what's the closest things, these things are one off from each other. So, let's just test those. So, let's set 10 up for height and 11 for takeoff height. Then, I will fill this in on the table, or board or have them filled in. So, we copy in the value for height, that's 10. Greater than, copy in the value for takeoff height, that's 11, question mark. Is ten greater than 11? No. False. Okay. Next column, copy in the value for takeoff height, 11. Copy in the value for height, 10. Is 11 less than 10? No. All right. Well, we have one case where they both evaluate, both of those expressions evaluate to the same thing. Let's try another case. Let's switch the other way. So, have height be slightly bigger than takeoff height. So, we'll go on and do that, and you'll see the 11 greater than 10? Yeah, that's true. 10 less than 11? Yeah, that's true. Okay. Always the crux case, well, not always, but in this case, the crux case, what if they're equal? So, we'll try this, 10 and 10. Is 10 greater than 10? False. Is 10 less than 10? False. Okay. Now, you and I are probably convinced right now that those are enough test cases to be sure that we've got these two expressions behaving the exact same way. You could talk with students about why do we not need more test cases to convince us. We could go, height could be zero and takeoff height could be 100. That's the same thing as testing height is 10 and takeoff height is 11, because we're just pushing the boundaries beyond. So, we've chosen cases that are closest around this less than, greater than thing, and we've chosen an equal case. That will give us the case. So, we can say that these codes do the same thing, because in each row, the expressions evaluate to the same thing. False in the first row, true in the second row, false in the third row. All right. So, what best describes what this code does? So, this would be one that the students would need to spend some time looking at. It's related to an answer that they or a question they've done before. But I entered in this UserAnswer less than two. My slide got messed up here. Okay. I'll tell you what the answer is. The answer is B. Says "pull up", if the current reported height is less than half the minimal height. So, this is no trick to it. It's really just interpreting the code. So, let's take a minute to go through it together. Asks, "How high are you?" and the user provides an answer. I'm storing in a value called UserAnswer and down in the bottom I say, "Current reported height". But that's interpreting what the code is actually should be doing, okay? So, I'm actually looking for students to pull away from the actual variable names to a little bit more abstract. I'll get some students that'll complain to me, "Well, you didn't say UserAnswer", and I'm like, "Well, Computer Science people need to be able to abstract away from specifics to general." So, can they do it? So then, really this just gets down to, can you read that expression and translate it to the appropriate english below. So, UserAnswer is really the current reported height, because it's going to ask you that and it's going to ask you that again and all those stuff. So, we say, if the current reporter height divided by two is less than half the minimal height, did I get that right? I'm thinking. This is a great, by the way, this happens all the time in my classes. Students catch me out and I'll have to fix it on the fly, and that's probably a good thing for students to see you. So, I was thinking I want it to be half the normal height. But if your height divided by two is less than minimal height. So, if my height is 100, and so if I say 50 is less than minimal height. So, I think that's wrong. I think it should be, if the current reported height, half of the current reported height is less than the minimal height, which would be exactly what we would read. Well, I hope you all had a good discussion around that in the interactive reading. I found this while recording and you know what, I'm not going to change it, because I hope you will have experienced in the discussion, in the interactive reading, the arguments that you can get into, self-doubting and going back and forth, and being like, "Is that really wrong?" Then say, "No, the professor is wrong". Yes, this is good, and it's a great thing to do with students in the classroom as well. Believe me, you're not going to need to intentionally do this, these things come up, all right? So, just let it happen naturally and be like, "Great. You guys figured it out, you had to discuss harder, because you thought maybe I did have it wrong, but you convinced yourselves, and then you convinced me." So, no matter if they got the question slightly wrong, my two goals were still accomplished in here. I really want students to be able to abstract away from the actual variable names to something that's a little bit more not directly using those variable names. Then secondly, I want them to be reinforced that we don't write code just for random stuff, it's supposed to actually do meaningful things. Clearly, we could have had a couple of different meaningful answers here. So, it's really important be able to put into english words what is the code doing, not just read it with the variable names in. Okay. Let's go on. Be hard to get this one wrong with a yes and no, but you never know. We'll try it. Should this code use a repeat until loop? So, I'm going to keep this by the way, really, really short. It's still using height in minimal safe height. So, in a way, the students don't feel as much like there's been a context switch. So hopefully, it won't be different. Too much more of a mental load, they'll be willing to engage with and there's few instructions. So, I'm asking something very different though, not how many times does it repeat, not what do they do. It says, should this code use a repeat, what do you mean should? It does. Well, hopefully, you've had a chance to discuss with them about the difference between repeat until and repeat. But if not, this will be a great way to do it. So, the answer is no. Why is that? Well, that's because this will happen a fixed number of times. We start with height equal to 100, and we can make a table like we've done before to do it, and we start with minimal height to 20. Basically, 100 is less than 20, no. So, I'm going to keep repeating, reduce it by 10, so that repeats once, by the way. Then, is 90 less than 20? No. That's my second repeat. 80 less than 20, 70 less than 20, this is what I do with students. 60 less than 20, sorry, 50 less than 20, 40 less than 20, 30 less than 20, 20 less than 20, no. It repeated five times, then we get down to 10 is 10 less than 20? Yes, so I don't repeat. Sorry, actually, I repeated nine times. So, this is really what I wanted to do, I could do it with a repeat nine times. Albeit, I realized it's a silly piece of code, but we want to reinforce with students the difference between when you can know how many times something is going to happen and when you don't know. Now, I think it's really important for students to understand the difference between these fixed versus conditional things. Is this code wrong? No. Is it going to work? Yes. So, it's an argument here, but one of the things that it's again, we're not just trying to create little programmers, we're trying to create students who understand the concepts of our programming language and what they allowed to do. So, in that regard, we could say, "We want you to recognize whether or not you should use a repeat until or not that this happens a fixed number of times, not a variable or conditional number of times." It's just if I ask it with those words, they know what the answer is because they're like, "It's reviewed until, so it must be condition or it must be conditional or something like that." So, that's why I do that one. This one is a great one to do with students because there are two correct answers. Let me give you a minute. We're still using that exact same piece of code and so we've just this a sort of a lead, a carryover from the last question. We've said in the last question that it didn't need a repeat until loop. So, I'm saying, which of these changes means that will cause us to use a repeating tool? So, we go from a fixed number to a conditional number. The overall view is here. Look, both A and B use random. A uses random outside of the loop to set the original height and B uses random to change the amount that you're changing the height by each time the loop. Either of those would cause you to need to use repeat until because if we just change the starting height, let's say, we change it to 200, well, now, we don't know how many times we're going to go. We're changing it to 200. We have to pick a random number between 50 and 10 or something like that. We won't know how many times that loop needs to loop and there's no way we could not know that as long as that's random. As long as that is random, that gives us enough. We don't knows for the thing to need to be repeated until. Switch over. Look at answer B. Suppose A was just set height to 100. If we just change the amount that it reduced the height by each time for some very number between negative one and negative 10, that would also be enough that we would not be able to say, it goes a fixed number of times. We won't know because it could be negative one, negative 10, negative three, negative five. It will change. But students will be tempted to say that both of them are acquired and it's really either or. So, by the way, I will absolutely get this, "But Dr. Simon, A or B wasn't an option, that's not fair." I say, "No. What's fair is me teaching you that you can logic it out and you don't always trust your expert." All right. So, some bit of randomization. Now, I'm not saying that if there are random and anywhere, if you randomly set a variable that has no value or is not used and changing how many times you go through the loop, it won't matter, but that concept of, especially in block these languages, if we use randomization or user input, that's going to give us some conditional loop that are potentially could give us a conditional loop, but we won't know how many times it's going to run. Second to last question, on the last two are very similar, again, really drilling down to the smallest number of instructions possible to really get at this, but to push on something that students struggle with, and they struggle with it because it feels very mathy, and I love to be able to use code, helps students get over their fear of Math. So, what do we do to figure this out? We set X to zero, repeating 100 less than X. A lot of times students have trouble with the number comes first rather than the variable. Then, by the way, what are we doing inside the loop? We change X by negative number, some random negative number and that reinforces the repeat until. This code will never quit. Why is that? Okay. Forget why is that. How would we figured out that that's the case? Hopefully, you send it. We're going to trace the variable value X. We've only got one of them, and I'm not even going to write in the expression to the right and the second column, although you could if you want to, but because we can probably do it in our head. So, X starts at the value zero. So, the very first time we hit that repeat, it says repeat until 100 less than X. Is 100 less than X? No. We repeat until something is true. So, we're going to change X now. We're going to go into loop, change X. We're going to change X by some negative amount. We can pick anything. We could pick me up. We can pick negative 20. We pick anything in between. Let's just pick negative one. All right. So now, we change it by negative one, it became negative one. Let's go back up to the top loop. Is 100 less than negative one? No. Okay, let's continue. Go into the loop. Change X by negative one again. Now, it's down to negative two. Repeat. Is 100 less than negative two? No. Things are not going well here, right? We're going south. Anyway, we're moving further away. We're trying to find if 100 is less than X. We want X to be bigger than 100 and in fact, it's getting smaller, and smaller, smaller all the time. Yeah, you can write code like that. So, in fact, the computer will just keep decrementing X by some value between negative one and negative 20, and just keep on going. Have to check and see if snap eventually throws an error because there is nominally a smallest negative number that any programming language can hold and can represent as the appropriate term, but that is beyond the scope of this course. All right. So, that was good. But by the way, since you'll be like, "What if you pick negative 20 instead of negative one?" Well, yeah, we can go through that. I didn't bother do the cross outs. By the way, whenever you're tracing variables, always do it on the board. It's so much easier than doing it in slides. So, my key takeaways of teacher trick here is teach students trace the code and when you have random, you can pick any value. It doesn't matter. For simplicity, I recommend that students pick one of the either values and always apply that. Otherwise, they're wasting brain cells, trying to pick a random value in the head. So, this code will run forever. It will never stop repeating. They have a good time. When you turn on the little footprints on the top, and let it, and so it shows you where all of them they're doing. It'll go too fast unless you put in a like a say, and a weight or something in there, and then you'll see or even just a weight would be enough. Then, they'll be able to watch the instructions as they get executed and keep going. Last one. Again, trying to keep the cognitive load low. I'm going to focus them on the concept and not figuring out a whole new problem. For exact same problems last time and so I tell them, "This is the highlight, the change that I made." So, you want to do that too. Highlight the change when that's the only part that's different. So, they can say, doing the same thing. That changes the answers. So previously, we said 100 less than X. Now, we're saying X less than 100. We use the same technique. We use a table, X starts off at zero. We repeat until it's true. Is zero less than 100? Yeah, it is. Well, wait. I'm already true. I repeat until true. It's true. So, you know what? I execute this loop body, the stuff in the loop, zero time. So, it's great to point out these two variations.
