 Hi, time for the mini lecture. And I'm gonna talk about the DeMorgan laws. So here's a nice little program that I've written and essentially what we're gonna tell people if they're between 1865, they don't get a discount. Everyone else gets a discount of 5%. So it's a discount for either young people or really old people. And there's nothing new in here at all, by the way. We're gonna ask them to enter their age. And if the age is greater than or equal to 18 and less than or equal to 65, that means they're between 1865 inclusive and tough luck, they don't get a discount. Otherwise, they get a 5% discount. And let's compile that and run it. So if somebody is, let's say 70 years old, they get a 5% discount. If they're 17, they get a 5% discount. If they're 42 years old, they don't get a discount. Again, absolutely nothing new here. Philosophically, a lot of people say, you know, I would really like to say that good news first rather than the bad news. So I want to reverse the sense of this test. Let's save this under different versions here so that you can see how this is going. So what I'm going to say, if it is not the case that the age is greater than eight, equal to 18, age less than 65, then they get the 5% discount. Otherwise, they don't get the discount. Now, this is a really artificial example, but there are some cases where the code reads a lot better if you do it one way than the other way. And let's compile that and we've run it. If somebody's 70, they get the discount. If they're 42, they don't. Now, here comes the problem. This is really weird to read. If it is not the case that the age is between 18 and 65, no, that's not the way we think in English. What we'd like to do is we would like to say, the opposite of this, and we want the opposite test of that. So the two conditions that we want are really if the age is less than 18, they get a discount. Age greater than 65, which is the opposite of less than or equal, then they'll get a discount. Now, here comes the tricky part. Do I want to leave this and in here? And the answer is no, I don't. Think about it. Can a person be less than 18 and greater than 65 at the same time? No, they can't. We have to change this and to an or to make it work. Now, we have the same thing. If the age is less than 18 or it's greater than 65, they get a discount, otherwise they don't. And let's save this as discount two. And when we compile it, I have one extra parenthesis, which certainly does not help. If they're 70, they get the discount. If they're 42, they don't get a discount. And if they're 17, they do get the discount. So in general, we need to know how to change expressions from positive to negative. So for example, so essentially if I have not condition one and condition two, that works out to the same as saying the opposite of condition one or the opposite of condition two. And again, we can use this example. Our first condition is age greater than or equal to 18 and age greater than or equal to 65. The opposite of that whole thing is going to be not age greater than or equal to 18 or it's not the case that the age is less than or equal to 65. Well, what's the opposite of greater than or equal? Less than. If something's not greater than or equal, it must be less than. If something's not less than or equal, it must be greater than. So this is one of the De Morgan laws. The opposite of this compound condition with an and is the opposite of the first condition or the opposite of the second condition. The other De Morgan law is as follows. What if I want the opposite of condition one or condition two? That works out to not condition one and not condition two. What you do is the not goes into each condition and the or changes to an and. If I'm doing the change with an and and changes to an or. Let's do an example of this. I want the not day equals three or day is four. Those are my two conditions. I think my first condition and may get a negative condition. My second condition, I take the opposite of that and I change the or to an and and that works out too. Day is not equal to three and the day is not equal to four. So those are the De Morgan laws. Lines two and six are the De Morgan laws. I am not going to go into a proof of why that works. I absolutely will not do that. You can do it by writing out a whole bunch of truth tables and I'm sure you can find some references that do it but I don't want to go into that at this point tonight. Now again, if you want to write it this way with a not on the whole compound condition, that's perfectly okay. You don't have to use the De Morgan laws but sometimes it makes things easier to read. This is a lot easier to read than that is. This one you have to sort of contort the English language to figure out what the heck that you're really talking about. Whereas here, oh yeah, less than 18 or bigger than 65, congratulations, you get a discount. And I guess I'll give you one more little feature here. I've got to write a program real quick here to make this happen. So let me pause the recording. Okay, here's the program. We're going to ask for a number of items sold and the number of customers. Make the English correct here. And if your grammar is not correct, I'm really not going to take off points for that but I just sort of, I like to have my grammar correct if at all possible. So we've given a number of items sold and a number of customers. If the average number of items per customer as an integer is bigger than seven, then it's a good day for sales, otherwise it's not. So I'm asking for the integer, number of items sold, number of people. And if the items sold divided by number of people here in the seven, then it's a good sales day. Otherwise sales today were sort of meh. And so we had a hundred items sold and there were nine customers. That's a good sales day. If we have a hundred people, a hundred items sold, excuse me. And there were 45 people. That's not a great sales day. Now here comes a problem. What happens if I say the number of those 100 and there were 10 customers but I accidentally drop off the one and I type it as zero. Boom. We get a runtime error because we're trying to divide by zero. 100 divided by zero is not a good thing to do. Now I'm gonna do something here. I'm going to check to see if the number of people is greater than zero and the items sold divided by the number of people is greater than seven, then it's a good sales day. Otherwise sales today were sort of meh. So if I have, again, 120 items with let's say, oh, 11 people, good sales day. And now if I say 120 and I accidentally put in a zero here, huh, wait a minute, how come that worked? This, here's the question some people ask. They say, well, wait a minute. Yeah, you tested this, but how come it didn't do the division anyway? And the answer is because of something called short circuit. Let's just take a look back at our truth table for and. We have condition A and condition B and we want to say A and B. So here we have true and true is true. True and false is false. False and true is false and false. Here's what we're taking advantage of. If I know that condition A is false, does it really matter what B is? Even if B is true, I still end up with false because they're not both true. If B is false, I still end up with false. So the moment I see condition A is false, do I really need to even look at B to figure out if it's true or not? No, I can cut things short. As soon as I know that I'm going to get a false answer, there's no need to go any further. Now, if the first condition is true, then the second condition makes a difference. I have to make sure that I have a B is true, otherwise it's false. But when I have a false, the decision is already made. Whatever B is, is totally irrelevant. Java takes advantage of this. Let's say the number of people is equal to zero. That means this is false. Because it's false, I know that this whole thing has to be false because, again, this second condition doesn't matter. The moment this first one is false, they can't both be false. They can't both be true, which means I never have to even look at this condition and the division never happens. So let me put a comment in here. When N people is zero, the first condition is false. That means the whole compound condition has to be false no matter what the second condition works out to. So I can totally ignore second condition and never do it at all. And that's why it worked okay when I put in a zero. Zero is not greater than zero. Java will never even look at that. This short circuits, the evaluation has also called early exit. I think I've seen it referred to that way. Now, so the number of people is seven, then that's true, which means I now have to do this division to figure out whether my result will be true or false. And in fact, again, let's say I have 80 items sold and seven customers, it's a good sales day. So this is early exit. Now, you put about early exit for the or condition. Well, let's look at the truth table for or I have and because I'm a little bit lazy tonight, I'm gonna copy this and paste it and change this to an or. In this case, when I have or, when the first condition is true, the second one doesn't matter. As soon as the first one is true, I don't care whether the second one is true or false, so they're both gonna be true. I don't have to evaluate condition B when A is true with an or. With an and when the first condition is false, I can do an early exit. So be aware that Java does early exit or short circuit evaluation because you can sometimes use it to your advantage to avoid runtime errors. It's not ultra important that you know about this, but it's nice to know. And that is a rather short, but oh, oh my goodness. Looks like I will have to do a mini lecture tomorrow. Yeah, what the heck? I'll do a mini lecture tomorrow because I just realized I forgot to talk about Boolean methods and Boolean variables. I was gonna do those tonight, but let's do those tomorrow because it's getting late and I'm probably going to be generating really bad code if I start doing something original right now. That's it for tonight. See y'all whenever.