lab04a
lab04a
witnessing bad arithmetic

We start by trying some expressions from lecture, to confirm that Java doesn't always give correct arithmetic answers. Predict the result of each expression to your partner, then try them out:

2.00 - 1.10
2000000000 + 2000000000
long n = 2000000000; n + n
1e20+3
(Recall that 1e20 is shorthand for 1·20)
Math.pow(10,309)
Math.pow(10,-309)
(Is this number positive-but-very-small, or is it negative-and-nowhere-near-zero?)
-1/1e-309
(What is -1 divided by an extremely tiny number?)
-1/(1/1e-309)
(Mathematically: 1/(1/x) = x, for all non-zero x.)
1e-324 / 4

Challenge: For each of above, classify the error as

round-off error (only possible with floating-point arithmetic)
overflow (can be integer or floating-point arithmetic)
underflow (only possible with floating-point arithmetic)

Order of operations

Challenge question:

What are the two possible ways to add parentheses to: false == false || true
See what Java returns. Which way did Java decide to add parentheses?
What is the moral of the story, about when to use parentheses?

Practicing with quotient, remainder

Remember that /, if given two integers, returns the quotient. The remainder can be obtained by % (pronounced “mod” or “modulo” in addition to “remainder”). Predict the result of each expression to your partner, then try them out:

260 / 100
260 % 100

int m = 260;
int n = 100;

m/n

(double) m                    // Casting.
double m                      // Error.
(double) m / (double) n       // integer division, or floating-point division?
((double) m) / ((double) n)   // Casting (w/ additional parens, for clarity?)

Task: Delicious SugarBomb donuts cost 65 cents each. A robot wants to be cashier, and needs to know what to say to customers, after the customer has told it how many donuts are desired. Complete the following function to help the robot out.

/** 
 * @param ____  The number of donuts ordered.
 * @return A String telling the customer how many 
 *    dollars and cents their order comes to.
 *  donutOrder(4)  = "4 donuts cost 2 dollars and 60 cents."
 *  donutOrder(__) = ______________________________________
 *  donutOrder(__) = ______________________________________
 */
String donutOrder( ___  ____ ) {





  }

Include comments and test cases, of course. Use a NAMED_CONSTANT to represent the price of a single donut.

Comparing `double`s

If you finish the preceding problem,

Comparing `doubles`

Edict of Programming: Do not use == with doubles.

After all, what is the value of this expression?

(2.0 - 1.1) == 0.9

So how do we see if two doubles are practically-equal? One immediate imponderable is “how close is close enough to be considered practically equal”? Well, for the moment let's say being within 0.001 is close enough: (y-0.001) < x < (y+0.001) is a start. (How do we write this math expression in Java? We'll need to use &&!) The amount “0.001” is called the “tolerance” of the comparison.

Task, part 1: Write a function nearlyEqual which takes in two doubles, and returns whether or not they are within 0.001 of each other. (Use a named-constant for the tolerance.)

Task, part 2: Actually, we should look at an relative difference between two terms, rather than an absolute difference. After all, 4.000000e6 dollars is practically equal to 4.000001e6 dollars, even though the difference between these two is one (which is far exceeds our tolerance).

Modify your program so that it returns true if the ratio of the two numbers is close to 1: that is, if (1-0.0001) < x/y < (1+0.0001). What is a test case for which this formula doesn't make work? Can you fix your code to handle that test case?¹

We won't finish this last problem in lab today, but it is worth completing as quiz1-study-material.

¹ A more subtle wrinkle: is your function symmetric — that is, if your program says that a is nearly equal to b, does that mean it will always say that b is nearly equal to a? If not, is this easy to fix? Is is important to fix it? ↩

home—info—exams—lectures—labs—hws
Recipe—Laws—lies—syntax—java.lang docs—java.util docs

©2007, Ian Barland, Radford University
Last modified 2007.Aug.25 (Sat) Please mail any suggestions
(incl. typos, broken links)
to iba�rlandrad�ford.edu