# teaching machines

## CS 145 Lecture 11 – Methods x4

September 30, 2016 by . Filed under cs145, fall 2016, lectures.

Dear students,

Let’s do one more of the exercises from last time!

Middle
public class Middle {
public static void main(String[] args) {
char a = 'a';
char e = 'e';
char middle = average(a, e);
System.out.println(middle);
}

public static char average(char c1, char c2) {
return (c1 + c2) / 2;
}
}


This problem introduces the ideas of promotion, upcasting, and downcasting. We will do a little science experiment to illustrate when we need to cast values between types.

Let’s order the types from greatest (most general) to least (least general):

1. double

2. float

3. long

4. int

5. short

6. char

7. byte


The rule of promotion is this: when an operator combines two operands of a lesser type and greater type, the result is always a value of the greater type.

Cast or Not? #1
double x = 45;
Cast or Not? #2
int i = 101;
double x = i;
Cast or Not? #3
short s = 0;
int i = s;
Cast or Not? #4
int i = 899;
long j = 900;
int k = i + j;
Cast or Not? #5
byte b = 127;
String s = b + " <- result";
Cast or Not? #6
public static void main(String[] args) {
short s = randomEven100();
}

public static int randomEven100() {
Random g = new Random();
return g.nextInt(51) * 2;
}
Cast or Not? #7
public static void main(String[] args) {
int i = 54;
labeledPrint("i", i);
}

public static void labeledPrint(String label, long l) {
System.out.printf("%s: %d%n", label, l);
}
Cast or Not? #8
public static void main(String[] args) {
int i = getInputInt();
int j = getRandomInt();
}

public static int getInputInt() {
Scanner in = new Scanner();
return in;
}

public static int getRandomInt() {
Random generator = new Random();
return in;
}

One of the nice things about this class is that we never set aside anything that we discuss. In chapter n, we still need all the concepts we discussed in chapters 1 through n – 1. That said, we close out our official focus on methods today. We have seen the Computer as Calculator, a lover of number crunching. We have seen the Computer as Chef, organizing its tasks into self-contained recipes. Next week we see the Computer as Philosopher, seeking truth from our data.

But that’s next week. Today, let’s have a look at some more methods. We start with some fill-in-the-blank exercises. Your task is to jot what goes in each blank of the following methods. One of the blanks is the method name. Pick something meaningful. The other blanks are not ambiguous. You should be able to deduce exactly what goes there.

FIB #1
public static _______ _______(int n) {
______ z = n + "";
return z.startsWith("-");
}

FIB #2
public static _______ _______(______) {
return text + " :)";
}

FIB #3
public static _______ _______(______) {
n = -n;
}

FIB #4
public static _______ _______(______) {
return s.charAt(s.length() - 1);
}

FIB #5
public static _______ _______(int n) {
_______ = "" + n;
_______ = s.replace("0", "");
_______ = s.length() - t.length();
return d;
}


We next turn to a problem that one of you asked on a quarter sheet. Is there anything like charAt for integers? Not exactly, but there’s nothing stopping us from writing our own method to accomplish this task!

Let me share with you a quotation from Maurice Wilkes, one of the developers of the first computers:

By June 1949 people had begun to realize that it was not so easy to get programs right as at one time appeared. I well remember when this realization first came on me with full force. The EDSAC was on the top floor of the building and the tape-punching and editing equipment one floor below… It was on one of my journeys between the EDSAC room and the punching equipment that “hesitating at the angles of stairs” the realization came over me with full force that a good part of the remainder of my life was going to be spent in finding errors in my own programs.

That “hesitating at the angles of stairs” is Wilkes alluding to the poetry of T.S. Eliot.

If we are going to be an inventor—even an inventor of software—we must care to do it right. We must make sure our software does its task well. To ease this burden, we’ll talk a little bit about test-driven development and write a primitive testing framework.

See you next class!

Sincerely,