CSCI A201/A597 and I210

Lecture Notes Eleven

Second semester 2000-2001


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 in 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 code fragments below.

So this is given.

Now the question:

Which of the fragments below set variable

i
to the 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;

And we use diagrams to reason about the programs. With time we won't need them, but to begin with they seem to be more intuitive.

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.

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.


That is they have the same output, and same sequence of internal states for identical inputs (over 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.

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.

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:


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?


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.

Questions:

  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?

  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.

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

Yes, and we can still do it. All right, let's do it! What's the motivation?

Remember the investment problem from the first week? Lecture notes two.

Exactly. 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 you'd want to do repeatedly until your balance doubles (reaches 20000).

Indeed. Java has a while statement which is able to do the iteration for us. And you'd only need to tell it when to stop or, rather, for how long it should go on.

Exactly. 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:

Last updated: Feb 4, 2001 by Adrian German for A201