Okay, to kind of feel like we stepped it up a notch on with our discussion questions a little bit. And I can provide some slightly simpler ones but these are really going to get kids. Even if they think they're gone wrong doing really well and there are some really good key points that need to come out of this. So this question the first one looked at how many times does this loop run? The answer is 15, and your brain should be going well, wait, 10 equal 10 less than 40, that's 30, I'm pretty sure that's 30, maybe it's 31 or maybe 29. But it's wrong there, it's not 15. Here is the trick, and I do this not because it should be tricky, but because this is a mistake students make all the time. When they're writing a four loop, they do the increment, when they write the four loop, i++. But when they get to the bottom, they may be thinking Y loop, or just like, I'm supposed to increment i here, and they'll write it out as well. And what that actually means is that the i will increment my 2, each iteration so it's going to go 10, 12, 14, 16, 18 etc. Two key things I want to point out here, first off the very bottom one, that if statement in there, that's totally a destruction. I just didn't want the second i++ to be really close to the first one. It's not doing anything, this code does not ask what this code, or the question doesn't ask what is the code do, it asks how many times it'll run. So just a distraction, you can have anything. The other thing is talking to your students about how do we figure out, let's throw away that i plus two thing. Like, if i starts at 10 and is less than 40, how do I know is that 29, 30 or 31? Well, tell them this, if it starts with something like 10, or 20 or 30, the zero there is just like you're into i = 0, and then you subtract off if it's 10, subtract off 10 off the upper values 40- 10. So i =10. Well, i is less than 40 is the same thing, i equals to 0, while i less than 30. Now, if you're using the actual value of i for doing something it might not be that. But if you're just counting how many times the loop runs, you'll know it. And then that i equal 0, i less that 30, our brains have memorized, [SOUND] that's 30. If it was one and less than or equal to 30, then that would be 30 as well. What does this code do? I mean this one is really mean. Look at the answers down there. There is no like, it finds some value or yeah it prints out this. It always loops infinitely, it sometimes loops infinitely, it always stops after a specific number of iterations, it always stops after some undetermined number of iterations. You may feel that this was really excessively hard. The AP CSA exam has some questions like this, that you can't just plug and chug, you can't just treat some code no matter how difficult and time consuming that may be, you have to analyze it. So this is a good one I think to start with. But if you had trouble with it, don't worry. Everyone else did too. So the first thing, up in the corner. Your students will be like, this is not fair. How do I trace code with random? I don't know what value it gives back to me. Yeah, that is in essence the problem. The answer to this question, so you know, it always stops after some undetermined number of iterations. And I say always, by the law of large numbers and the way random works, if we let it go long enough, it is going to stop. Turns out in practice, and I'll show you some sample output, happens really fastly. But usually less than 10 iterations. Why? Okay, let's start by looking over the code. We got i = 100. So it's a 100 while i is greater than 0, so gee, I hope i is going down, otherwise this loop will run infinitely. So i's got to get less than or equal to 0 for us to stop. And we've got one number and another number, again, they often put these crazy names like completely abstract names on these kind of questions so that you don't have anything else to go with. The key thing here is actually we're going back and remembering how math.random works. And then understanding what range of values would be in what num and what range of values would be in another num. Not that you know what's going to be on any given iteration but by understanding the range, we can analyze and make an argument. So Math.random gives you a value between zero, a double value between 0 and up to and not including one. So up to 0.9999999, and so if you want it to give you 50 values, you multiply that by 50. That gives you 0 up to and including 49 because 0.99999 times 50 rounded down to cast to an int is going to be 49. And by the way, if you forget those cast to an int, you're going to get compiler errors, that's a possible loss of precision. anotherNum. The difference here is, before the column Math.random, I have a -1. So this is going to produce our negative value. So my idea is, can we skip down to the third line? That we're going to have our ID updated by whatever it was and add on some number. And since we hope that this is going to get lower and lower, that number hopefully is going to be negative a lot of the time, otherwise i is never going to get reduced. So oneNum+anotherNum hopefully needs to be negative. Let's go back to anotherNum, it's negative, okay, and I'm multiplying by 100. So that means every time I call anotherNum, I'm going to get a value between an inclusive of -99 to 0. So I've got positive 0 up through 49, and -99 up through 0. Well, there's a lot greater chance I'm going to get bigger negative numbers like bigger than 49 because that's an option. Whereas with the positives, the biggest one I can only get is 49. So given that things run off, enough enough, many, many, many, many calls to random, there's just a greater chance I'm going to have a negative overall value when I add up oneNum+anotherNum and then add that on to i. So eventually, I'm going to get down and the loop will stop because i will become less than or equal to 0. Previous value of i + something on average is going to be negative. That's the takeaway. That said, this is something students will not believe, unless you show it to them. So I have, again, a replica with all of the code for the solutions of all of these problems with some debugging statements in there that you can turn on and turn off. And what you want to do is here is you want to print out for them for each iteration, what is the value in oneNum, what is the value in anotherNum, so they can see the positive and the negative. And then also, after we've updated i, because we already did that above this red box. What is that? And then I did a count, count wasn't part of the program but I wanted to see how many iterations it'll take till I stopped. And at the end I've got another down below the red box, I've got another debugging statement, it says it printed. We ended after this many iterations, okay? And it's like really less than 20 a lot, and a lot of times it's really short, but it will vary every time you run it and you should run this code multiple times with your students. So here is one iteration I run. Remember I started at 100. So the first print is oneNum, oneNum apparently came up to 20, that random call, anotherNum was -23. That wasn't very small or lives really close, so you can see then 20 + -23, that's negative 3. Add that on to 100. That's going to get you to 97. The next iteration up, 97 is that greater than zero? Yes. Okay, oneNum came up to 49. Yeah, anotherNum can be up to -74, that's great. Add those together, I don't know what that is, but to subtract that difference off of 97 you can get i is going down to 72. This is good, we need i to go down, right? Down until it gets negative. Sorry. And then you can see it the rest the only two more iterations that it takes because anotherNum was -65, and negative, those numbers are bigger than the possible positive number which was 49. And i is going to end up being -17 after only four iterations. But sometimes it takes longer, here's, again, I didn't change anything, I just ran the code again because random will behave differently each time. The first version of oneNum is 41 and anotherNum is -2, my gosh, this is bad, i is going up. Sometimes i is going to go up, right? Because 41 + -2, that's 39, 100 + 39 is 139, so it goes up. Now you can see they're going down, down, down, let's go all the way to the bottom. And eventually, we were above 100 there for a lot of times, those i values are all but over 100 but then anotherNum is negative 60, yes, anotherNum is 85. Yes, and i is dropping and anotherNum is negative 50 and we ended it after nine iterations. So in analyzing this, some iterations, i is going to get larger, some iterations is going to get smaller, and most iterations, i is going to get smaller and possibly by a lot. If we're only starting at 100 and it's possible you can end up with a -99, we could go really quickly. So that's why it will always stop after some number of iterations because it's on average, we're going to be having a negative value added on time, not every time but on average.
