Spring Semester 2002


Lecture Notes Ten: Branches and paths. If statement exercises. (L)oops.
What's the purpose of if statements? It allows us to include decisions in our programs.

What do we do with their results? We can branch our course of action.

How do you code this branching situation?
Use the space above.

Did you remember to use curly braces? I try to do this as often as possible, it helps me keep all my branches distinct.

That's good practice. Indeed, even though sometimes I don't really need the brackets.

How would you code this slightly modified situation?
I see there's one minor change.

It may look minor on the diagram. I see... Now I have to use brackets.

Yes, there's no way around it. Otherwise the branches tangle.

In general, in our programs, we have the flowchart clear in mind and we just need to translate it into Java. But we need to do that with care, as illustrated above, and curly braces are more than just syntactic sugar in Java.

Ocasionally we will have to do the reverse, ... that is, build the diagram out of Java text,

... when we read someone else's code. Let's see some examples.

OK, here's a bigger one. I can hardly wait.

Bigger Example One Assume that option is an int variable that can only be: 1, 2 or 3 before each of the following code fragments start executing.

So this is given. Yes. Now the question.

Which of the fragments below set variable i to the same value that option has? We will look at this kind of problems with the help of diagrams, as announced before.

The (given) code is on the left, the diagram is on the right, in all examples below.

Code Diagram
if (option == 1) 
  i = 1;
else if (option == 2) 
  i = 2;
else 
  i = 3;

In this particular case it's easy to see that the code sets i to the same value as option ... given the assumption about the possible values that option can have. We just explore all paths.

For the remaining of these notes we only sketch the diagrams here, ... and fill them with text in class.

Code Diagram
i = 1;
if (option >= 2)
  i = i + 1;
if (option == 3)
  i = i + 1; 

Code Diagram
if (option == 1)
  i = 1;
if (option == 2)
  i = 2;
else 
  i = 3;

Code Diagram
i = 1;
if (option > 1)
  if (option > 2)
    i = 3;
  else 
    i = 2;

Don't forget we still need to provide an answer with each one of the diagrams. Indeed we need to say whether the code fragments presented are (or not) equivalent to
i = option;
... which is the equivalent code.

If the equivalent code is that simple, why do we go through all this trouble, to rephrase a simple assignment statement? We chose a simple situation to practice if statements on it. Don't worry, I have a list of suggested exercises indexed at the end of these notes, below. Those are real iffy situations.

Very good. So we keep things simple while we learn the concept, and we use diagrams to reason about these simple, illustrative programs. Indeed, we rely on diagrams for the time being. With time we won't need them, as you'll be able to see them without drawing them, but for beginners they seem to be more tangible.

Here's the last case:
Code Diagram
i = 1 if (option == 1);
i = 2 if (option == 2);
i = 3 if (option == 3);

Incorrect syntax, no diagram.

But, you get a Picasso.

Time to move on. Bigger Example Two


Consider this code fragment
if (x > y)
  z = z + 1;
else 
  z = z + 2;
Which one of the following (code fragments) are equivalent to it? Two code fragments are be considered equivalent when they behave in the same way.

Two code fragments are to be considered
equivalent
... when they behave
in the exact same way.

That is they have
  • the same output, and
  • same sequence of internal states
for identical inputs,
... over their all possible inputs.

Note that the structure of the diagram is as important as what gets written inside the boxes.


We sketch the diagrams below. And leave the reasoning to you.

Code Diagram
if (x > y)
  z = z + 1; 
if (x <= y)
  z = z + 2;

So, what's the answer? Those paths are not independent, I don't think.

How about this next one, then?
Code Diagram
if (! (x > y))
  z = z + 2;
else
  z = z + 1;
This one is much easier to think about, no doubt about it. But careful thinking is required when the problem is posed, as it is, with its upside down.

How about this next one, then?
Code Diagram
z = z + 1;
if (x <= y)
  z = z + 1;

Not harder, but somewhat unfamiliar (p. 75).


How about this next one, then?
Code Diagram
if (x > y)
  z = z + 1;
else if (x <= y)
  z = z + 2;
If the last one was efficient this one's redundant.

How about this next one, then?
Code Diagram
z = z + 2;
if (!(x > y))
  z = z - 1;
The approach looks a bit contortive this time.

Like this? No, that's circular, not even recursive.

I think it's more like this:
That, my dear friend, is Paul Klee. With your permission.

Bigger Example Three Consider the following two program fragments:
Fragment 1 Fragment 2
if (x == 5)
  x = x + 1;
else 
  x = 8;
if (x == 5)
  x = x + 1;
if (x != 5)
  x = 8;

Check all that apply:


I think this is a bit involved. Very well, then, here's a hint.


There's more to it than meets the eye. That much is clear.

Bigger Example Four Assume that x and y are integer variables.

Then consider the following nested if statement.
if (x > 3)
  if (x <= 5) 
    y = 1;
  else if (x != 6) 
    y = 2;
  else 
    y = 3;
else 
  y = 4;
If y has the value 2 after executing the above program fragment, ... then what do you know about x?

Did you have to draw a diagram?
No, I used a sculpture this time.

Bigger Example Five
Assume that x and y are integer variables, ... and consider the code fragment shown below:
if (x > 3) { 
  if (x <= 5) 
    y = 1;
  else if (x != 6) 
    y = 2;
} else 
  y = 3;
I hope you noticed the difference between it and the previous one (Bigger Example Four).

You bet. Now the questions.

Question 1.

If x is 1 before the fragment gets executed what's the value of y after the fragment is executed? (Is it possible to give an answer to this question?)


Question 2.

Now erase the curly braces. What value must x have before the fragment gets executed, for y to be 3 at the end of the fragment?


What do you think about these problems? They make for good practice.

Would you happen to have more? More? You mean, real problems, programs?

Yes, to practice even further. I actually do.

Very well, where are they? Here's a set of warmup problems of the kind you seem to be looking for.

Here are my solutions. You're pretty quick, aren't you?

Yes, and ready for more. Then here are some programming problems of the kind you seem to be looking for.

And I think you should work them all out.
Weren't we supposed to start loops today.

Yes, and we can still do it. Then let's go for it!

What's the motivation? Remember the investment problem from the first week? It was presented in lecture notes two.

Here's the code in Java, most of it. What is in red and what is in blue?
double balance = 10000;
int year = 0; 

year = year + 1; 
balance = balance + balance * 0.05;

System.out.println("Year: " + year); 

The code in blue should be executed only once. The part in red looks like what one would want to have done repeatedly until the balance becomes big enough, or doubles (or reaches 20,000).

In Java there is a while statement which is able to do the iteration for us. Like if is a composite statement. With it one only need specify the red part, with an indication of when to stop. Or, rather, for how long it should go on with the computing of it.

Here's the code:
double balance = 10000;
int year = 0; 

while (balance < 20000) { 
  year = year + 1; 
  balance = balance + balance * 0.05;
}

System.out.println("Year: " + year); 
Can I draw a flowchart for this?

You sure may. Here it is:

It takes a while to understand all this, ... but once you do it you're home free.

Last updated: Feb 5, 2002 by Adrian German for A201