Welcome to the IPL Zone

(Introduction to Programming Languages, Periods C and E)

Are you nervous when you see NCWEE? concerned when you see CIRC? perturbed when you see PBC? Visit Mr. Hansen’s fabled abbreviations page to make sense of those cryptic markings you see on your papers.


Schedule at a Glance (see archives for older entries)
Written assignments should follow the HW guidelines.


W 1/22/14

Snow day.


Th 1/23/14

C period: Introduction; discussion of Fortran, COBOL, Grace Murray Hopper.
E period: No class.


F 1/24/14

Both periods: Discussion of class policies, including Mr. Hansen’s three rules.

E period only: Introduction; discussion of Fortran, COBOL, Grace Murray Hopper.


M 1/27/14

HW due: Send a test e-mail (double underscore required at beginning of subject line) in which you identify yourself by name. See Mr. Hansen’s contact information if you forgot to copy down the e-mail address in class last Friday.

In class: Formal vote on languages to study during the semester; beginning of curriculum; a brief history of the digital electronic computer.


T 1/28/14

C period does not meet today.

HW due (E period): Visit eclipse.org/downloads and download the Eclipse Standard 4.3.1 development environment for your platform (32-bit or 64-bit). Download this onto either a laptop or a desktop computer, or both if you have both.

In class: Installation of Java 7 Update 51 and Eclipse Standard 4.3.1.


W 1/29/14

HW due (C period): Same as yesterday’s assignment for E period, plus the additional item shown below for E period.

HW due (E period): Visit http://java.com/en/download/installed.jsp and run the procedure (see link on left side of page) for removing older versions of Java. The only version you should keep on your machine is Java 7 Update 51.

In class (both C and E): Generations of programming languages.


Th 1/30/14

C period will meet for about half a period, and E period does not meet today.

In class (C period): RAM, disk storage, flash RAM, cache RAM, price of computing, Moore’s Law, KMGTPEZ.


F 1/31/14

HW due: Review your class notes. No additional written work is due.

In class (C period): Hex notation, “quite sizzly” rules, 162 = 256, 210 = 1024.
In class (E period): Quiz, RAM, disk storage, flash RAM, cache RAM. We will catch up on price, Moore’s Law, KMGTPEZ, hex notation, “quite sizzly” rules, 162 = 256, and 210 = 1024 on Monday.


M 2/3/14

HW due (everyone):

1. Download the Java textbook, and read Chapters 1 and 2, which are numbered as pp. 1-22 in the page headers. Reading notes are required (see link at top of calendar for the HW guidelines for standard formats). Your reading notes may be brief, and legibility is up to your judgment alone, but you must have some reading notes.

2. Write Exercise 1.1 (all 3 parts) on p. 11. Again, follow the standard HW guidelines given in the link at the top of the calendar. We will do Exercises 1.2 and 1.3 in class, but you are welcome to work ahead if you wish.

In class (E period): Price of computing, Moore’s Law, KMGTPEZ, hex notation, “quite sizzly” rules, 162 = 256, and 210 = 1024. C period has already covered these topics.

Both classes: 1 byte = 8 bits = 2 hex digits; 1 nybble = 4 bits = 1 hex digit.


T 2/4/14

HW due:

1. Read the paragraph at the top of p. 12, above Exercise 1.3.

2. Perform Exercise 1.3, parts 1-9. Describe your findings briefly on your HW paper.

3. Perform Exercise 2.2 on pp. 22-23. After your program runs correctly, transcribe it onto your HW paper. Use the “quite sizzly” rules for any variable names. Note: Be sure to include at least one comment line beginning with double forward slash ( / / ).

In class: A quiz (10 pts.) is possible on the words found in the glossaries on pp. 9-11 and pp. 21-22


W 2/5/14

HW due:

1. Finish up yesterday’s assignment if you have not already done so. See Mr. Hansen before 3:30 p.m. today (Wednesday) for additional credit if you did not earn full credit on Tuesday.

2. Read Chapter 3, pp. 25-37. Reading notes are required, as always.


Th 2/6/14

No class.


F 2/7/14

HW due: Study the glossaries at the ends of Chapters 1-3. A closed-notes quiz is possible. There is no additional reading or writing assignment due, since many students had a play to attend on Wednesday night and were unable to do much HW that night.


M 2/10/14

HW due: Pick a partner, if you wish, and start writing a program to answer the problem described below. Everyone must have something written (or printed out) to show today. If you have a partner, then each partner should have something written (or printed out) to show today.

Completion is not expected. Correctness is not expected. However, effort and written evidence of work are expected. All written work should be 3-hole punched and stored in your binder.

Problem: Given any date between 01/01/1900 and 12/31/2099, inclusive, determine the day of the week.

We will do this by adding the number of 12’s found in the final pair of digits in the year (YY), plus the remainder, plus the number of 4’s found in the remainder, plus the month code, plus the day value. That result is then divided by 7, and the remainder tells us the day of the week (0 = Sunday, 1-5 = Monday through Friday, 6 = Saturday). Integer arithmetic is used throughout.

Month codes for January through December are 0 3 3 6   1 4 6 2   5 0 3 5.

Exceptions: Subtract 1 if the date is in January or February of a leap year. Subtract 1 if the year is 2000 or greater. (That means that if the date is in January or February of a leap year and in a year greater than or equal to 2000, you must subtract 2.)

Examples that you can try with your program to see if it gives the correct result:

YY = 01
Integer division by 12 gives 0, with remainder 1, and there are 0 “fours” in that remainder of 1. Month code is 5 for September, and the day is 11. Total is 0 + 1 + 0 + 5 + 11 – 1 = 16, and the remainder when 16 is divided by 7 is 2. Answer: Tuesday.

YY = 14
Integer division by 12 gives 1, with remainder 2, and there are 0 “fours” in that remainder of 2. Month code is 3 for February, and the day is 10. Total is 1 + 2 + 0 + 3 + 10 – 1 = 15, and the remainder when 15 is divided by 7 is 1. Answer: Monday.

11/22/1963, the day John F. Kennedy was assassinated
YY = 63
Integer division by 12 gives 5, with remainder 3, and there are 0 “fours” in that remainder of 3. Month code is 3 for November, and the day is 22. Total is 5 + 3 + 0 + 3 + 22 = 33, and the remainder when 33 is divided by 7 is 5. Answer: Friday.

10/29/1929, the day the stock market crashed (“Black Tuesday”)
YY = 29
Integer division by 12 gives 2, with remainder 5, and there is 1 “four” in that remainder of 5. Month code is 0 for October, and the day is 29. Total is 2 + 5 + 1 + 0 + 29 = 37, and the remainder when 37 is divided by 7 is 2. Answer: Tuesday.

02/29/2012, the most recent leap day
YY = 12
Integer division by 12 gives 1, with remainder 0, and there are 0 “fours” in that remainder of 0. Month code is 3 for February, and the day is 29. Total is 1 + 0 + 0 + 3 + 29 – 1 – 1 = 31, and the remainder when 31 is divided by 7 is 3. Answer: Wednesday.


T 2/11/14

HW due: Continue working on your day-of-the-week program. Some additional things to keep in mind:

1. Be sure to include comments. At a minimum, comments must include your name, the revision date, and an explanation of any variables or lines of code that are not already “self-documenting.”

2. Use of descriptive variable names is encouraged.

3. When checking for errors, you should not only verify that the given date is within range (between 01/01/1900 and 12/31/2099, inclusive) but also that the date is valid. For example, 02/29/1900 and 04/31/1929 should both be rejected.

4. When your program is working correctly, move it from being a standalone module (i.e., public static void main) to being a method (e.g., public static String DayOfWeek) that accepts one or more arguments for the date and returns a string for the day of the week. That will allow you to call the DayOfWeek method dozens of times from within your main routine, and that will vastly improve your ability to perform error checking. Hint: Your method can return an error message as a String instead of the name of the day of the week if the input is invalid. If you can’t do this on your own, do as much as you can, and we will work on it together in class.


W 2/12/14

HW due: Continue working on your DayOfWeek method. Make sure that it returns a String and that it works correctly when called from the main method by a statement like this:


Your DayOfWeek method should accept integers in the format MM, DD, and YYYY as input, and it should return a string (by means of the
return statement) to the main method. Try to do as much of this as you can outside class, and we will work on it again during class.

In class: Mr. Hansen will replace the contents of your main method with a “test suite” consisting of a few dozen lines similar to the one above.


Th 2/13/14

No school (snow).


F 2/14/14

No school (teacher professional day).


M 2/17/14

No school (holiday).


T 2/18/14

Here are some test data lines that you can paste into your main method:


































W 2/19/14

Quiz will cover glossary terms (Chapters 1-3 only), thinking like a computer, thinking like a programmer, and possibly some short snippets of code to write.

HW due today: Write 20-30 test cases for putting your program through its paces (or more than 30 if you wish). Instead of using all randomized data, use the guidelines given in class for constructing good test cases. Try to fix all of the bugs in your program so that it passes all of your test cases. Then you will be ready for alpha testing, which we will begin today in class.


Th 2/20/14

No class.


F 2/21/14

HW due:

1. Improve your test data. In C period, the example we looked at had good coverage of error conditions but insufficient coverage of valid dates. In E period, the situation was largely reversed: reasonably good coverage of valid dates but insufficient coverage of error conditions, boundary cases, and multiple errors within the same input. Note: Thorough coverage of valid dates would require thousands of test cases. Don’t carry it to that extreme.

2. Exchange your improved test data with someone else in either section (C or E period, your choice), and act as each other’s alpha tester. Work with the other student to understand the discrepancies between what both of your programs produce in response to both sets of test data. Label each discrepancy as “WAD” (works as designed), “potential bug,” or “known bug.” For example, if your program validates years first, and your friend’s program validates months first, then a call to DayOfWeek(14,7,2108) might cause your program to return “ERROR--year out of range [1900,2099]” while your friend’s program returns “ERROR--month must be between 1 and 12, inclusive.” You would label this situation as WAD, since both programs are working exactly as they were designed.

3. NOTE: Although you may share ideas, no copying or pasting of code between students is allowed. An exception is made for test data written as lines of code. For example, it is OK (and expected) that you will share lines such as


but you are not permitted to e-mail or copy-and-paste snippets such as

    if (year % 4 == 0) {
        running_tally = running_tally - 1;
        leap_year_flag = 1;

4. When both programs appear to be working correctly on both sets of test data, ask one or more family members to act as beta testers. Do not steer your beta testers toward any particular type of test data, other than to tell them that 3 integers are required. (The compiler will automatically reject any non-integer input.) It is quite common to find bugs during beta testing that were not caught during alpha testing. Good luck!

5. Copy and paste your source code for your entire Java class (including your personal set of improved test data) into the body of an e-mail message whose subject line is formatted as follows:

    __20140220 DayOfWeek ver. 0.90 beta [Lastname, Firstname]

Comments in your code should include your name, the due date (20140220), the version number (0.90 beta), the names of your alpha and beta testers, and a brief description of what you learned during alpha and beta testing. Send your message to Mr. Hansen.


In class: We will conduct a code review of randomly chosen students’ programs. Don’t worry if your program isn’t quite perfect yet. It’s still in beta!


M 2/24/14

HW due: Using some of the hints you learned during last Friday’s code review, prepare an even better beta version of your program. Use the following subject line:

    __20140224 DayOfWeek ver. 0.95 beta [Lastname, Firstname]

Note: If time permits, some individual comments on your previous submission may be sent to you by e-mail before midnight on Saturday evening. Try to incorporate these suggestions into your 0.95 beta release. If you receive nothing by midnight Saturday evening, you may assume that the general suggestions given in class on Friday are adequate for your situation.


T 2/25/14

No class (Diversity Day). A double assignment is posted for tomorrow.


W 2/26/14

HW due:

1. Read Chapter 4 (pp. 39-47) if you have not already done so. Much of this material should be familiar to you already, since you have already made use of it in your DayOfWeek method.

2. Read Chapter 6 (pp. 55-68).

3. Write Exercise 6.2 on p. 69. Perfection is not expected. Effort (and written evidence of that effort) are expected. Bring a hard-copy printout of your code to class.

4. Suppose that you have advanced to the rank of division manager at a medium-sized software firm. One of your programmers comes to you and proposes that she receive, instead of an annual salary, a simple fee based on so-and-so-many cents per line of code that she writes.

(a) Would you accept such a proposal? Why or why not?

(b) If your boss, the senior vice-president for technology, insists that you honor your programmer’s proposal, what additional clauses would you insert into your programmer’s contract to make sure that she does not take undue advantage of the situation?


Th 2/27/14

No class.


F 2/28/14

HW due: Write Exercise 6.9 on p. 73. Skip the optional challenge on p. 74. Note: The book should have said that n is a nonnegative integer. Therefore, include an error-checking line that prints a message if n < 0. If n = 0, that is usually not an error; the return value is always 1 if n = 0, unless x is also 0, in which case a different error message should be printed: “Zero to the zero power is undefined.”

In class: Recursion.


M 3/3/14

HW due: Answer the following questions. These will not be collected until tomorrow (Tuesday), but on Monday you should be able to demonstrate significant written evidence of progress toward the goal.

1. In C period, we came up with the following code for our  
power  method.

      public static double power(double x, int n) {
          if (n==0) {
              if (x==0.0) {
                  System.out.println("ERROR! UNDEFINED!");
                  return -9999999.9;    //error value
              return 1;
          return (x * power(x, n-1));

(a) Is this method recursive? How can you tell?

(b) One bug this method has is that a negative value for n will cause a major failure. Identify the problem (using the terminology from our class) and explain why the problem occurs.

(c) Come up with a fix for the bug described in part (b). Test your fix to make sure it works. (A handwritten code snippet or a printout of your source code is required.)

(d) Another bug in the method as written above is that 0 raised to a positive power, which should return 0, will instead return an error message and an error value. There are several ways to correct this bug. Find a way, and test it to make sure it works. (A handwritten code snippet or a printout of your source code is required.)

Note: If you wish to make a single printout that addresses both (c) and (d), be sure to use comments to indicate which lines are fixing which bug.

2. Mr. Hansen’s grandmother, who died at age 96, would always answer the question, “What time is it?” by saying, “A little later than it was a little while ago.” Even though Mr. Hansen was too young to read a clock, he was able to add fractions. Assume (1) that the phrase “a little later” always meant about half an hour, (2) that Mr. Hansen asked his grandmother the time at approximately half-hour intervals, and (3) that the young Mr. Hansen always woke up at 8:00 a.m. and knew what time it was then, because that is when he always woke up.

(a) Write a paragraph explaining how the young Mr. Hansen could have used a stack (LIFO) of slips of paper in order to determine the time, at least to the nearest hour.

(b) Is the procedure you described in part (a) recursive? If your answer is “yes,” then how can you tell, and what is the base case? If your answer is “no,” then how can you tell that the procedure is not recursive?

3. Write Exercise 6.10 on p. 64.

In class: Glossary Quiz (possibly a double quiz) covering terminology from the glossaries of Chapters 1, 2, 3, 4, and 6.


T 3/4/14

HW due: Complete the 3 problems assigned over the weekend. If you finished them all yesterday, then you have no additional written HW. Hooray!

In class: Review.


W 3/5/14

NORMAL CLASS, EXCEPT ON A FRIDAY SCHEDULE. The event that Mr. Hansen was originally supposed to attend today has been canceled. Today is a “Friday” schedule with short periods.

HW due: Review problems of your own choosing. Keep a time log to document at least 35 minutes of time on task. A hard copy of your time log is required, but if your review consists of programming problems, a hard copy of your work on those problems is not required for today.

In class: Review.


Th 3/6/14

No class (as usual). Note: The review period originally scheduled for today has been canceled and will be held on Wednesday instead.

Here is Ellie’s Quizlet for learning your vocabulary words. Note: This is offered “as is” and is not guaranteed to be 100% free of errors. However, you will probably find it useful. Thanks to Ellie from the E period section!

And here is George’s Quizlet, similar but with some of the in-class terminology. Note: As with Ellie’s Quizlet, this is offered “as is” and is not guaranteed to be 100% free of errors. Thanks to George from the C period section!

Some terms and concepts covered in class (e.g., hexadecimal, binary, 1GL, 2GL, 3GL, 4GL, DLL, Moore’s Law, KMGTPEZ) are not currently included in the Quizlet. However, you are still responsible for knowing them.


F 3/7/14

Test (100 pts.) on Chapters 1, 2, 3, 4, and 6, plus everything discussed in class.


M 3/10/14

As announced at the test last Friday, there is no additional HW assignment due today. Get some good sleep! Enjoy the beautiful weekend weather!


T 3/11/14

HW due:

1. Read the glossary to Chapter 7 (p. 86) and all of Chapter 8 (including the glossary). Reading notes are required, as always. Reading notes are for your benefit and are not required to be especially legible. However, they must be in handwritten form.

2. Write Exercise 7.1 on p. 87. Use a table similar to the one shown below to organize your work.

3. Write Exercise 8.1 on p. 100. Be sure to use a loop counter to step backwards through the string. Here is some pseudocode to get you started, but you do not need to use it if you prefer to use your own approach:

public static void ReverseString(String InputString) {
    let maxlen = length of InputString;
    let i = maxlen;    //scratch (loop counter)
    while i is still positive {
        print the “i”th character of InputString (but not println)
        decrease i by 1
    println      //so that all the accumulated characters are printed on a single line

Note that your code must be in “real Java,” not the phony pseudo-Java used above. Bring a hard-copy printout of your code to class. (A handwritten version is also acceptable, since this method is so short.) If time permits, test your code by calling your method from main with a line such as

    ReverseString("Washington, D.C.");
Also, note that the loop needs no input error checking, since the loop is never entered if InputString is a null string.


W 3/12/14

HW due:

1. Read Chapter 9 (pp. 107-116, including the glossary). Reading notes are required, as always.

2. Below is a (bad) attempt to implement yesterday’s Exercise 8.1. Correct all the syntactic and semantic errors, and provide a comment (either handwritten or as a Java comment) for each change you make. Make sure that your final version works correctly, and test it with a variety of test data as input, including the null string. Make a hard copy (either printed out or handwritten) of your final working version.

public static void main(String[] args) {

    System.out.println(ReverseString("Washington, D.C."));


public static void ReverseString(String InputString) {
    maxlen = length(InputString);

    i = maxlen;    //scratch (loop counter)

    while (I > 0) {



    System.out.println("");  //so that all accumulated characters are printed



Th 3/13/14

No class.


F 3/14/14

Happy Pi Day! HW due:

1. Reread Chapter 9, at least one more time. Twice more is recommended, since there is a lot of difficult material there, and it takes a while to soak in. As you come up with questions, write them in your reading notes.

2. Do Exercise 9.3 on pp. 118-119 (all 4 parts as described below). Before you begin, be sure to read the documentation of the
grow method at the link provided.

    Part 1. Make a sincere effort to answer part 1 without entering the program into Eclipse.

    Part 1A: Then, run the program and see what you can learn about the difference between what happened and what you thought would happen. Write a short paragraph comparing the output that you saw versus what you thought you would see. Explain what, if anything, you learned from the exercise. If your initial prediction was completely correct, then perhaps you learned nothing, and you can write that, but that would be unusual. Remember, we learn much more from our failures (including inaccurate predictions) than we learn from our successes.

    Part 2: Draw the state diagram as requested, using the notational style and arrows illustrated in the text.

    Part 3: Answer the question about aliasing. Be sure to explain your answer.

3. Pi can be calculated by adding up the following infinite series: . The notation, which may not be familiar to you, can be interpreted as follows: “The summation, starting from n = 0 and proceeding for all integer values 0, 1, 2, 3, and so on, of terms equal to 4(–1)n/(2n + 1).” The notation is a shorthand for writing out the following:

The notation uses a capital sigma, the Greek letter that traditionally indicates a sum. (Get it? S for sigma and sum?)

Obviously, we can’t add terms from 0 to infinity. However, we can write a Java program that uses a loop to add up the first 5000 terms (i.e., terms where n = 0 through n = 4999). Do this, and see how close your answer is to the true value of pi by printing your answer after exiting the loop. Hint: Use a double variable called sumInProgress, initially set to 0.0, to store the sum. Inside your loop, add 4.0/(2*n+1) to the previous value of sumInProgress if n is even, and subtract 4.0/(2*n+1) from the previous value of sumInProgress if n is odd.


M 3/17/14

Snow day (no school). Happy St. Patrick’s Day!


T 3/18/14

HW due:

1. Read Chapter 12 (pp. 149-158, including the glossary). Reading notes are required, as always.

2. Write Exercise 9.1. Use any format you find helpful for part 1. Try to do part 2 without entering the code into Eclipse; then try it and see how close your prediction was.

3. Write Exercise 12.5. Hard copy (handwritten or printout) is preferred, but for today, a running copy of your code on a computer will be acceptable.

4. Write Exercise 12.7.

5. Write Exercise 12.12. For now, pseudocode is acceptable. We will write actual Java code in class.

In class: Finish Exercise 12.12 and review for tomorrow’s quiz.


W 3/19/14

Big quiz on all recent material. Terms added to the board yesterday were as follows:

backward compatibility
error checking
firmware (software embedded in hardware)
degrading gracefully
“Users are losers.” (Not really. However, it sometimes seems that way.)
unit testing
regression testing
end-to-end (system) testing
acceptance testing
test plan
log file
dump (PMD)



Spring break. Your quarter grade will be e-mailed to you by approximately March 31 or April 1.


M 3/31/14

No additional HW due.


T 4/1/14

HW due: Download the online C++ text and read Chapters 1 and 2 (pp. 1-19). This should go quite quickly, since the book is by the same author who wrote the Java text we used, and you can focus on the syntax differences between Java and C++. You will find that the languages are quite similar—but just different enough to drive you crazy at times.

Reading notes are required (as always).


W 4/2/14

HW due:

1. Write a C++ program that declares and initializes an integer (not string) variable to your birthdate in the format YYYYMMDD. The program should then use mathematical operations (integer arithmetic, modulo arithmetic) to print output formatted as follows:

The date is MM/DD/YYYY.

Remember to include at least one comment line in your program.

If your birthdate was March 15, 1998, then your integer variable would have the value 19980315, and your output would look like this:

The date is 3/15/1998.

Hint: You may wish to sneak a peek at Chapter 4 (p. 33). Integer division and modulo arithmetic should look like old friends to you by now.

2. Write the same program in Java. Include a comment line in which you comment on which version is easier, or if they are about the same.

3. If you have a C++ IDE (integrated development environment) at home, go ahead and execute both programs to make sure that they run. If you do not have an IDE at home, use longhand for now. Bring your hard copies (either from the IDE or written out in pencil) to class.

Note: We will enter the program on the lab computers later, after Eclipse for C++ is installed (probably by this weekend).


Th 4/3/14

No class.


F 4/4/14

HW due:

1. Read Chapters 3 and 4 (pp. 21-40) in the C++ text. Reading notes are required, as always.

2. Write a short educational program in C++ that uses recursion to teach the concept of factorials to junior-high students. If you have a working IDE (Integrated Development Environment) and compiler, go ahead and test your code with several different starting values. Otherwise, just write out your code using pencil and paper, and use stack diagrams (like the ones we used in Java) to make sure that your code is essentially correct. The requirements are as follows:

(a) At least one “fancy comment” block is required. You can put this at the beginning or at the end, or if you can find a suitable place in the middle, that is also permitted.
(b) An int variable, in main, should be initialized to an integer value of your choosing. Use any name you wish for this variable.
(c) The educate_factorial function will then be called, using that int value as the argument.
(d) The educate_factorial function must perform error-checking by immediately rejecting any value less than 0 or greater than 12. The function will print a suitable error message and will not proceed any further (i.e., will return) in that case.
(e) If the input is 0, the educate_factorial function must print the number 1 and a newline character.
(f) If the input is any valid integer other than 0, the educate_factorial function must print that integer followed by a space and the word “times” and another space; after that, a suitable recursive call to educate_factorial must be made.

3. Why is 13 considered invalid input for the program described in #2?


M 4/7/14

HW due: In keeping with the spirit of the NCS Backpack By Choice (BBC) weekend, there is no homework over the weekend. However, if you would like to get a little bit ahead and have an easier workload heading into Tuesday, then go ahead and read Chapters 5 and 6. They are available online, as you know.

In class: Configuration day to make sure that everyone has a working C++ IDE and compiler. If time permits, we will also discuss recent material from the textbook.


T 4/8/14

HW due:

1. Read Chapters 5 and 6 (pp. 41-65). Reading notes are required, as always.

2. Short C++ programming assignment. The requirements are listed below.

(a) First, read through all the requirements, and see if you can shorten the list without changing anything.

(b) The body of the main method must resemble the following:

int x; //scratch variable
x = 301;
cout << "The reverse of " << x << " is "  << reverseInteger(x) << endl;
x = 792;
cout << "The reverse of " << x << " is "  << reverseInteger(x) << endl;
x = 570;
cout << "The reverse of " << x << " is "  << reverseInteger(x) << endl;

(c) The reverseInteger method, which you will write, must accept an integer argument between 0 and 999, inclusive. Any other argument value should cause reverseInteger to return –9999 as its return value and print a suitable error message.

(d) The reverseInteger method must use at least 3 local variables, at least one of which must be named x. All local variables must be declared at the beginning of the method. If their meaning is not completely clear from the names you choose, you must use comments to make their meaning clear.

(e) At least one "fancy comment block" beginning with /* and ending with */ is required.

(f) Given an integer of format xyz where all digits x, y, and z are nonzero, the reverseInteger method is to return the integer zyx (i.e., 3 digits in reverse order). For example, reverseInteger(348) should return 843.

(g) Given an integer of format xyz where one or more of the digits x, y, or z are 0 (or implied to equal 0 if the integer represented by xyz is less than 100), reverseInteger is to return the integer whose value equals the integer zyx. For example, reverseInteger(340) should return 43 (not 043), and reverseInteger(802) should return 208.

(h) The value of reverseInteger(0) should equal 0.

(i) An integer having two implied leading zeros, of format x where x represents a single digit, should cause reverseInteger to return the value x00. For example, reverseInteger(7) should return 700.

(j) For an integer having two trailing zeros, e.g., 800, reverseInteger should return the value of the sole nonzero digit. In this example, reverseInteger(800) should return 8.

(k) Given an integer with exactly one trailing zero, i.e., of format xy0 where x and y are both nonzero digits, reverseInteger is to return the integer of format yx with no leading zeros.


W 4/9/14

Read Chapters 7 and 8 (pp. 67-87). Reading notes are required, as always.


Th 4/10/14

No class. Tomorrow’s assignment will be a single assignment, not a double assignment, since the STA sophomores have a required evening event on April 9.


F 4/11/14

HW due: Write a simple program that meets the requirements listed below. Techniques are illustrated in Chapter 8.

(a) The program should ask the user what his or her name is (via the system console).
(b) The program should accept a line of string input from the user. Regardless of what that line is, it will be treated as a valid name.
(c) The program should then thank the user, by name, and suggest a good restaurant. Use the name of a restaurant that you personally enjoy.


M 4/14/14

HW due: Write a program that meets the requirements listed below. It is not expected that everyone will get all the way to the end, since there are oodles of opportunities to make mistakes. Do the best you can, get as far as you can, and list in your comments the people who helped you along the way. Each student needs to write his or her own program. Most of the code is already written for you below and can simply be copied and pasted. However, be sure to READ THE COMMENTS!

(a) The program should ask the user for his or her name (using getline).

(b) The program should address the user by name and ask for the user’s birthdate in the format YYYY, MM, and DD on separate lines of input. In other words, there will be 3 inputs, and there should be a prompt for each one: year (ENTER), then month (ENTER), then day (ENTER).

(c) The user probably wasn’t born at noon UTC, but this program will assume that that’s the case, for simplicity. In other words, the user’s birthdate will be treated as MMMMDDYY 12:00:00 UTC.

(d) The program should validate the year (between 1901 and 2013, inclusive) and issue an error message if the year is not within those bounds.

(e) The program should validate the month (between 1 and 12, inclusive) and issue an error message if the month is not within those bounds.

(f) The program should validate the day (between 1 and 31, inclusive) and issue an error message if the day is not within those bounds. Note: Dates such as 19970231 will therefore be treated as valid. However, you will see that the date arithmetic that follows later will simply treat such a date as if it had been entered as 19970303.

(g) Determine the current hour, minute, second, day, month, and year (in UTC) by pasting the following C++ code. Note that you may have to resolve some naming conflicts manually!

    int month, day, year, hour, minute, second;  // scratch variables for current time


    //scratch variables to hold time data

    time_t rawx;

    //time_t is a standard C++ data structure defined in the ctime header

    //(and that means we need #include <ctime> at the top of our code)

    struct tm* info; //info is a pointer to the object we get when converting a time structure


    rawx = time(&rawx); //gets current time (to the nearest second)

    info = gmtime(&rawx); //converts time structure to UTC 24-hour clock


    month = info->tm_mon;

    month++;   //Convert from 0-based month to normal (1=January, etc.)

    day = info->tm_mday ;

    year = info->tm_year + 1900;

    hour = info->tm_hour;

    minute = info->tm_min;

    second = info->tm_sec;

(h) Pass those values (month, day, year, hour, minute, second) to a method called getSeconds, provided below, whose purpose is to determine how many seconds have elapsed since midnight on January 1, 1900. Note: There is a bug in the code, since leap years between 1/1/1900 and the date passed to the method are not accounted for. If you wish, you can attempt to fix that bug for extra credit. Be sure to add comment lines if you do that.

int64_t getSeconds(int month,int day,int year,int hour,int minute,int second) {

    int monthSeconds; //seconds in the current year, before the start of the current month


    switch (month) {

        case 1:



        case 2:



        case 3:


            if (year % 4 == 0) {

                monthSeconds += 24*3600;



        case 4:



        case 5:



        case 6:



        case 7:



        case 8:



        case 9:



        case 10:



        case 11:



        case 12:




            cout << "Internal error! Value for month must be between 1 and 12, inclusive!";

            monthSeconds = 0;



    return (int64_t) (year-1900)*31536000 + monthSeconds + (day-1)*24*3600 + hour*3600 + minute*60 + second;


(i) Pass the user’s birthdate information, along with the UTC hour, minute, second of 12, 0, 0, to the getSeconds function.

(j) Subtract the result of (i) from the result of (h), and display the output in an infinite loop that says

____, you are approximately ___________ seconds old.

Note: The blanks are to be replaced by the user’s name, which was captured in (a), and the user’s age in seconds, which is to be continuously updated.

Also note: For young people such as you, the subtraction can be performed correctly using standard arithmetic. However, for users that are over age 60 or so, the number of seconds elapsed may exceed the capacity of a regular “int” variable. Also, if you save the results before subtracting one from the other, you should declare variables of type int64_t (equivalent to a long in Java) to hold the results from requirements (h) and (i). If your compiler chokes when you try to declare variables of that type, not to mention the getSeconds method itself, which is also of that type, you may need to put an #include <cmath> statement at the top of your code.

(k) Since the output is in an infinite loop, the user must be knowledgeable enough to click the “red square” to terminate the program.


T 4/15/14

HW due: Repair all the problems with your code in the “age in seconds” application. You may work with other students as long as you document (in your comments) the assistance that your receive. Outright copying of code is prohibited, except for the code given in the 4/14 calendar entry.


1. The documented bug in getSeconds must either be repaired or properly documented in the comments.

2. The undocumented bug in getSeconds, the bug that was found by Emma in period C and by Becky and Jennifer in period E, must be repaired.

In class: Review.


W 4/16/14

Test (100 pts.) on all recent material. You may be asked to write short code segments in Java, C++, or both. The time_t structure will not be tested. (That’s what reference books are for.) Minor errors (e.g., forgetting an occasional curly brace or semicolon in either language) may be forgiven. Once again, terminology—both from the book and from in-class discussions—will be emphasized. Also, be alert for one or more “critical thinking” questions concerning situations in which you have almost no experience or direct knowledge. (Think, for example, of the hiring decision between Bob and Brenda on the last test.)


Th 4/17/14

No class, but your HW is due at 2:00 p.m. today. You can come to MH-102 during your usual period if you wish to have some one-on-one help.

Collaboration with other students is permitted only if you document their assistance in the comments. Submit your code in the body of your e-mail, not as an attachment. If indentation is lost, that is regrettable, but we’ll accept it. (Loss of indentation will not count against you, as long as your original code uses good indentation practice.) Use the following subject line format when submitting your code (change Lastname, Firstname to your own name):

    __20140417 LifeSeconds ver. 0.90 alpha [Lastname, Firstname]


F 4/18/14

HW due: Make sure you have submitted your HW project (see yesterday’s entry), and read Chapter 9 on pp. 89-97. Reading notes are required, as always.


M 4/21/14

HW due:

1. Read Chapter 10 on pp. 99-110. Reading notes are required, as always. For full credit, notes must conform to the formatting standards specified in the HW guidelines.

2. Write a C++ function called STA_random (or NCS_random, if you prefer) that accepts 3 integers as parameters. You can (and should) call your 3 integers by more meaningful names, but I will refer to them here as i, j, and k. Your function should print k pseudorandom integers that are between i and j, inclusive. Your function must avoid the techniques described near the bottom of p. 104, since those do not work in Eclipse. Instead, you should use the following boilerplate code:

#include <stdio.h>

#include <stdlib.h>

#include <iostream>

using namespace std;

Then, include a line that “seeds” your pseudorandom number generator as follows:


The number 31 is merely an example. Use any nonnegative integer less than 32768 that you wish. Now, you can generate a pseudorandom double between 0 and 32767 (inclusive) every time you have a line in your code that looks like this:

double xx = (double)rand()/RAND_MAX;

So, what do you do with xx? Since xx is approximately uniformly distributed on the interval [0,1] (that’s math notation for the interval of real numbers from 0 through 1, inclusive), you should be able to figure out a way to scale that up to the interval [i, j] that the STA_rand function should be spanning. Print the result (as an integer, not as a double), and do this a total of k times.

This is a moderately challenging task, especially since your textbook gives you little guidance that you can use. If you cannot finish by Monday, bring a time log and your written stumbling attempts to class, and we will discuss them. By Tuesday, you should have a function that is largely bug-free and can be tested by other students.


T 4/22/14

HW due: Finish your STA_random (or NCS_random) function.


W 4/23/14

HW due: Write a program that utilizes good programming patterns (comments, encapsulation, meaningful variable names, etc.) to implement the (AX + B) % N linear pseudorandom integer generator discussed in class. Experiment with different values of A, B, X0 (seed value), and N (modulus value) to find several combinations that produce reasonably long and random-looking cycle lengths. N should be a power of 2. The requirements for this assignment are deliberately left rather vague so that you can creatively explore some options on your own. For example, you may prefer to hard-code the values of A, B, X0, and N, or you may prefer to let the user enter them at runtime. You may wish to have the values A, B, X0, and N passed to a function so that you can see the results of many efforts at once.

Notation: X as used here denotes the output of the pseudorandom integer generator. You should use a more meaningful name. Each value of X is determined by subjecting the previous value of X to the (AX + B) % N formula.

Some “cool” features to consider including in your program (try to incorporate one or more if you can):

1. Auto-detection of the point at which cycling starts to occur
2. Storing outputs in a vector (as suggested in the textbook)
3. Compiling statistics on frequency counts (histogram) to see if the distribution of outputs is relatively uniform
4. Checking to see if patterns are seen in the absolute value of the differences between successive outputs
5. Analyzing the distribution of the quotient of 2 successive outputs (a question that came up in one of the sections)
6. Analyzing outputs for even or odd parity to see if there are any obvious patterns


Th 4/24/14

No class. However, you can come in during C or E period if you desire some one-on-one assistance with your program.


F 4/25/14

HW due:

1. Start a new project called MonteCarlo. This project will utilize portions of the code you wrote for Tuesday (i.e., STA_random or NCS_random) and/or portions of the code you wrote for Wednesday (i.e., the (AX + B) % N linear pseudorandom integer generator that you built) as a way of generating thousands of random integers between 1 and 6, inclusive.

2. In the comments, explain the reason for your choice of algorithm. For example, you might not have had sufficient confidence in the uniformity of the distribution from Wednesday’s assignment, or you might not have gotten Tuesday’s program (STA_random or NCS_random) to work correctly. Do not use as an excuse the fact that you couldn’t figure out how to convert integers from 0 through N – 1 (in Wednesday’s program) to integers in the set {1, 2, 3, 4, 5, 6}, because there is an easy way to do that. (See sample code in the appendix below.)

3. Generate 10,000 pseudorandom integers from 1 through 6 to simulate the rolls of 5,000 pairs of dice. The question of interest is this: Given that both dice are odd, what is the probability of rolling a sum of 6?

4. Use counter variables in your program to keep track of the number of pairs of dice that have been rolled, the number of times that both simulated dice were odd, and of those, the number of times that the 2 dice added up to 6. For example, you could have a counter initialized as

int pairsCounter = 0;   //keeps track of # of times a pair of simulated dice are rolled

and then, after every 2 successful calls to rand() or to your (AX + B) % N linear pseudorandom integer generator, just do this:


5. Display the following statistics:

Total number of pairs rolled: ___________ [should equal 5000]
Total number of times both dice were odd: ___________
Of those, the total number of times the dice added up to 6: ___________
Estimated probability of a sum of 6, given that both dice are odd: ___________

6. Note that the last blank must be computed as a floating-point value. The other statistics are all integers. The last blank is computed as the quotient of the blanks immediately above it. For example, if you have 1260 times that both dice were odd, and if 441 of those had a sum of 6, then your probability estimate would equal 441/1260, or 0.35.

Appendix: Sample code for converting pseudorandom integers into the set {1, 2, 3, 4, 5, 6}

Suppose that your (AX + B) % N linear pseudorandom integer generator has N = 65536. That means that, if you were clever, you might have been able to find a set of values for A, B, and X0 (the seed) such that 10,000 or more values will spew out before you have any repeats.

Let X denote the current output. Since we know that X is an integer between 0 and 65535, inclusive, we could simply discard X and request a new one if X is 60000 or more. That leaves us with X between 0 and 59999, inclusive. If we integer-divide X by 10000, we should get a result between 0 and 5, inclusive. Add 1, and we have a perfectly good simulated die roll.

Here is code to do that (assuming that X or something like it has already been declared and produced as an output):

while (X >= 60000) {
    X = (A*X + B) % N;    //produce another value for X
int die1 = (X / 10000) + 1;

X = (A*X + B) % N;        //produce another value for X; keep it only if X < 60000

while (X >= 60000) {
    X = (A*X + B) % N;    //produce another value for X
int die2 = (X / 10000) + 1;

pairsCounter++;           //must increment since we have valid die1 and die2 values

This code could be improved further by encapsulating the
(A*X + B) % N logic in a function, but that is not required.


M 4/28/14

HW due: Finish up the previously assigned projects. If your programs are already “code complete” and fully debugged, then you may take the weekend off. However, feel free to try one of the optional challenges below.

Optional Challenges

(A) Add a bar-graph output feature to show the distribution of die rolls. For example, you could design your output to look something like this, with one “X” for each 40 rolls of a certain value:


(B) Design a Monte Carlo simulation to estimate the mean number of runs of length 5 that occur when a fair coin is flipped 100 times. By “run” we mean 5 heads in a row or 5 tails in a row. If 10 or more heads or tails occur together, we would count that as 2 runs. It may be surprising to you that the mean number of runs of length 5, when a fair coin is flipped 100 times, is more than 3.

(C) Modify the simulation in challenge B so that you can estimate the probability of having at least one run of length 5 when a fair coin is flipped 100 times. (As you might expect, the probability is close to 1, since the mean number of runs is more than 3.)

(D) Here’s something you can do even without doing challenges A, B, or C, and it can be fun. After your program is debugged, you can try it out on friends or family members.

First, your program should ask the user to enter 100 coin flips. You can accept 100 individual inputs of H or T, which is rather tedious, or you can accept a single line consisting of 100 characters, which is also tedious. Choose whatever approach you prefer, but maybe you would like to accept 10 inputs of 10 flips each. For example, the user might enter these lines:











Now, here’s the fun part. Have your program scan the input (considered as a single 100-character string), looking for “HHHHH” or “TTTTT” as part of the string. We know that the probability of having at least one run of HHHHH or TTTTT in a random coin-flip stream is extremely high, but most users don’t know that. If the user gives you input that includes at least one run of 5, you could compile some simple statistics on the number of heads and tails and issue a message thanking the user for taking the time to play the game. However, if the input includes no runs of HHHHH or TTTTT, then you could issue a message making fun of the user for trying to pass off a fake list of coin flips as the real thing. It’s your chance to engage in some mild verbal abuse:

Hey! Who do you think you are? That wasn’t a random list of coin flips. Try again!

You can also make fun of the user if there are 62 or more heads (or 62 or more tails) in the input, since a truly random stream of coin flips would usually be much closer to the expected 50/50 split. To get 62 or more heads or tails is something that would happen by chance alone only about 2% of the time. Thus you would be fairly safe in accusing the user of fakery if there were 62 or more heads, or 62 or more tails, in the user’s input.


T 4/29/14

HW due: Read Chapter 11 (pp. 111-121). Reading notes are required, as always.


W 4/30/14

HW due: Celebrate the end of April by getting a good night’s sleep, for a change!


Th 5/1/14

No class.


F 5/2/14

HW due: Start working on the following project. Chapter 11 will help guide you but will probably not answer all of your questions.

1. The expectation for Friday is not a completed project. Your objective, for now, is to produce some written design documentation that will help you work toward the project. “Written design documentation” means notes that coherently describe how you intend to proceed. Snippets of code are permitted but are not yet required to be syntactically valid. More important is to describe, in a combination of English sentences and pseudocode, what it is that you intend to do and how you will do it.

2. Include two or more of the following: a flowchart, some pseudocode that resembles C++ (or even Java, if you prefer), and personal notes describing what you already know how to do and what you are still unclear about. Actual C++ code is optional at this stage. In fact, if you write code but fail to produce your two or more other required elements, you will not earn full credit.

3. The project requirements are to implement your previous day-of-the-week algorithm as a member function. In other words, when the user inputs a birthdate, you will validate the date and will create a object for it (of type Birthdate, a new type that you have to figure out how to create) that has the day, month, and year as instance variables (all ints). Then, if the user requests the day of the week for that date, you will invoke a member function to produce the answer.

4. If you are able to produce working code, that is great, but it is not expected. In fact, there is a real benefit in taking a little extra time to think about your design before you implement it.

Note: Design documentation as described above will earn full credit, even if you have no code at all yet. Code without design documentation will earn no credit.


M 5/5/14

HW due:

1. Prepare higher-quality design documentation for the project described in the 5/2/14 calendar entry. A flowchart (or equivalent) is required this time. Note: This flowchart will not really be for the code you write (since your program is primarily object-oriented, not procedural). However, show the “START” and the part where you gather the instance variables for your date object. For the part where the user may or may not request the day of the week, show a decision diamond with two branches, one of which includes the entire day-of-the-week logic that you programmed previously in the course. Note: For goodness’ sake, do not include the code itself. For one thing, that code was in Java, not C++. For another, this would be a perfect opportunity to use your hexagon symbol. See additional ideas below if you are still a little confused.

2. Something to think about: What is the power of encapsulation? Don’t write your answer down; simply think about it and be prepared to say a few words on Monday.

3. If your design is sufficiently detailed and you feel confident that you can implement the steps in your flowchart, you may proceed to coding and testing. Translating your existing day-of-the-week code from Java to C++ should be relatively easy.

Additional thoughts on part 1 above:
Your design documentation won’t be very lengthy. In fact, you may have already finished most of it.

The project requirements (see 5/2 calendar entry) say that you are to ask the user for a birthdate, validate the date, create an object for it, and then “if the user requests the day of the week for that date, you will invoke a member function to produce the answer.”

Think of how you might show this in a flowchart:

(a) Ask user for birthdate (parallelogram).
(b) Validate date (rectangles, several of them, with decision diamonds to determine whether the date is valid).
(c) Create object (rectangle).
(d) Loop in which you wait for some action to occur. In a game, you might imagine your loop waiting for someone to strike the “show day of week” button with a direct hit from a high-energy laser (or whatever). But since we don't have any fancy game engine to use, the easiest way for you to implement the logic would be to have the program ask the user whether he wishes to have the day of the week displayed, and as long as the answer is anything other than “yes,” keep looping. When the answer is “yes” (or at least no longer “no”), you can have your flowchart branch to the older code you wrote (hexagon), which denotes the member function for the object.


T 5/6/14

HW due: Work on the project that was assigned last week. Some working code (including struct statement) is expected before the start of class today. If you are able to produce a fully functioning program that meets all requirements, so much the better!

During class, we will have some additional time to work. However, be prepared to show written evidence at the start of class that you have made progress toward building working code. Your written evidence may take the form of a program listing (hard copy) or live code that you display on your screen when your homework is spot-checked; either format is acceptable for today.


W 5/7/14

HW due:

1. Finish your C++ “member function” project. If there are any remaining bugs, they must be documented in the comments. If there are any portions that still do not compile, you must document those problems as well.

2. Download the Python textbook, and skim Chapter 1 (pp. 1-8). Then read Chapters 2 and 3 (pp. 11-29) in more depth, paying special attention to the differences between Python and the other languages we have studied. Reading notes are required, as always.


Th 5/8/14

No class.


F 5/9/14

HW due:

1. E-mail your completed “member function” project code by e-mail, using this subject line format:

    __20140509 MemberFunction ver. 0.90 alpha [Lastname, Firstname]

Remember to paste your code into the body of the message. Do not send an attachment. All known issues/bugs (including lack of indentation, if that is a feature of your e-mail client) should be documented in the comments. If your code does not compile yet, be sure to note that, also.

2. Visit www.python.org, and click on the orange square marked with the prompt symbol. It looks like this: >_

3. Use the interactive shell to execute a “Hello, world!” program. (This is a one-liner.)

4. Use the interactive shell to execute the following program that prints the first 15 nontrivial Fibonacci numbers, namely 2 through 1597 (you may omit the comments):

    i=1 #first Fibonacci number (before start of nontrivial numbers)
    j=1 #second Fibonacci number (still before start of nontrivial numbers)
    k=0 #scratch variable for a nontrivial value; will be adjusted in loop
    n=1 #loop counter for nontrivial Fibonacci outputs
    while n<=15:
        k=i+j #next nontrivial Fibonacci number
        print(k,"is nontrivial output no.",n)
        i=j   #update i in preparation for next iteration
        j=k   #update j in preparation for next iteration

Note: You have to press the ENTER key twice at the end so that your program will run.

5. Modify the program you wrote in #4 in order to find the 20th nontrivial Fibonacci number. Write the answer in your homework binder, on a sheet dated 5/9/2014.


M 5/12/14

HW due: Read Chapter 5 (pp. 41-49), and solve both parts (1 and 2) of Exercise 5.4.

Note: Use of Python (interactive or compiled) is encouraged, but you may use Java or C++ to solve Exercise 5.4 if you wish. In class today, we will work through the Python solution as a group.


T 5/13/14

HW due: Practice your Excelcise (see 10/28/2010 calendar entry here).


W 5/14/14

HW due: Continue practicing your Excelcise. Everyone must pass. The 5-minute time limit is reasonable, but only if you practice your skills.


Th 5/15/14

HW due: Continue practicing.


F 5/16/14

No required class, but the room will be open during C, E, and F periods if you wish to come in and try to pass. Personalized one-on-one help will also be available during those times.


M 5/19/14

Guest Speaker: Mr. Joseph Morris of MITRE Corporation will speak on the subject of cybersecurity. Mr. Morris is a 1962 graduate of STA and has more experience in the computer field than all 34 of us put together!

Please note, nine (9) students in C period and eight (8) students in E period still need to pass the Excelcise. You may come in during F period or after school.


T 5/20/14

Review day. Please note, the students listed below still need to pass the Excelcise. You may come in during F period or after school.

C period students: Daniel, Justin, Zack, Hugh, Nick, Neil
E period students: Ellie, Ryan, John, William, Thomas, Julia, Nat


W 5/21/14

Field Trip to the NSA/National Cryptologic Museum. Coat and tie are not required (per yesterday’s lunch announcement by Headmaster Wilson), but please wear a shirt with a collar (males) or respectable non-beach wear (females). No sandals or flip-flops, please. We are ambassadors of STA/NCS and want to represent the schools well. Bus departs at 8:00 a.m. from the service road near the Martin Gym. We will be back on campus by 1:15 p.m., in time for lunch.

Note: If you are unable to go on the field trip, you must do this alternate assignment (do problems 1-8 all, and ignore the indications about “Form”). Turn in your alternate assignment at lunch to Mr. Hansen at table 38. The alternate assignment will be graded. NCS students who are not on the field trip may submit the alternate assignment for grading at the start of class on Friday.


Th 5/22/14

No class. MH-102 will be open for Excelcise competition. There are still 12 students who have not passed.


F 5/23/14

Exam review.

Check out Nick K.’s nearly excellent quizlet at this link.


T 5/27/14

Final Exam, 2:00–4:00 p.m., SB 201-202.

Format will be as follows:

Part I: Vocabulary and terminology (approximately 35 points). This section may include a mixture of fill-in-the-blank, matching, and/or multiple-choice questions.

Part II: Essays (approximately 20 points). Thoughtful responses, using complete sentences, are required. Topics may include specific issues related to good coding (patterns), avoidance of bad coding (antipatterns), or other matters discussed during the course.

Part III: Coding and translations (approximately 45 points). Code may be provided in Java, C++, or Python, most likely with bugs and/or missing comments. You may be asked to correct the bugs, add comments, and/or translate into other languages. Since we did not do much with Python, your ability to write Python code will not be tested strenuously. Calling by reference will not be tested.

You may bring a single “cheat sheet” (standard 8.5" by 11" size, or filler paper size) on which you have written your boilerplate code. Thus, you will not have to memorize things like

public static void main(String[] args) {


#include <iostream>

#include <cstdlib>

#include <stdio.h>

#include <stdlib.h>
#include <vector>

using namespace std;

You will probably want to review the textbook sections having to do with declaring and traversing strings and arrays, just to make sure that you remember how the syntax works. If you want to include a few lines of sample code on your cheat sheet, that will be acceptable.

Important: If you choose to make a cheat sheet, be sure to write your name on it. Standard size is required. (No mini-sized cheat sheets!) Your sheet will be collected at the beginning of the exam, checked for suitability, and returned to you while you are working on your vocabulary and terminology section.


Links Based on Class Discussions:
-- Latest revision of the MODD course outline from 2005, before we had a good textbook to use
-- Homemade “Segway”-like balancing scooter uses a fair amount of calculus!

Serious Links:
STA School Handbook
-- Summer math camps for talented high school students
-- Click here for other serious links

Return to Mr. Hansen’s home page

Return to Mathematics Department home page

Return to St. Albans home page

Last updated: 30 May 2014