This piece of software performs graph partitioning on graphs with biweighted vertices. Both weights are divided among the pieces of the partitions.

The software is a single file of source code and can be downloaded here.

Documentation for BHS is available here.

2000 ACM Programming Contest

The 2000-1 ACM North Central North American Regional Programming Contest was held simultaneously at numerous sites throughout the region on Saturday 11 November 2000.

In particular, Lake Superior State University, Sault Sainte Marie, MI, hosted teams from several schools:

Algoma University College, Sault Sainte Marie, Ontario, Canada
Lake Superior State University, Sault Sainte Marie, Michigan, USA
Michigan Technological University, Houghton, Michigan, USA
Northern Michigan University, Marquette, Michigan, USA

The contest consisted of 8 problems to be solved over a 5 hour period. No official solutions were published, so what follows are my solutions, written in ANSI C.

Problem 1

Problem 2

Problem 3

Problem 4

Problem 5

Problem 6

Problem 7

Problem 8

For more information, please visit the official contest site.

2000 ACM PRACTICE CONTEST

The 2000 NMU ACM Practice Contest was held from 5:00 to 10:00 P.M. EDT on Thursday 26 October 2000 at Northern Michigan University. The contest was attended by 4 teams. The purpose of the contest is to determine which two teams from NMU will attend the North Central North America ACM Regional Programming Contest this year as well as to provide our teams with practice. Since only two teams expressed interest in being NMU's official representatives, this contest served as practice only.

The teams were as follows:

Competing officially:

Boy Wonder--Renaye Jurczak, Sarah Larson, Dave Newman
The Matrix--Mike Kowalczyk, Carlo Razetto, Denny Vandenberg

Competing unofficially:

Hobos with Guns--Russell Langkawel, Joe Schmeltzer, Carey Stortz
The Unofficial Programmers--Ben DuPont, Keith Rutkowski

The contest consisted of 6 problems to be solved over a 5 hour period.

Here is the list of problems.

Below is the list of test input files, correct output files, and sample solutions. There were many ways to solve the problems, of course. These solutions were developed using the C++ compiler of DJGPP (the Gnu C Compiler for Windows).

Problem 1
Problem 1 Input File
Problem 1 Output File
Problem 1 Solution

Problem 2
Problem 2 Input File
Problem 2 Output File
Problem 2 Solution

Problem 3
Problem 3 Input File
Problem 3 Output File
Problem 3 Solution

Problem 4
Problem 4 Input File
Problem 4 Output File
Problem 4 Solution

Problem 5
Problem 5 Input File
Problem 5 Output File
Problem 5 Solution

Problem 6
Problem 6 Input File
Problem 6 Output File
Problem 6 Solution

Here are the complete results. Congratulations to The Matrix for winning the Practice Contest.

1999 ACM Programming Contest

The 1999-2000 ACM North Central Regional Programming Contest was held simultaneously at numerous sites throughout the region from 1:30 to 6:30 P.M. EST on Saturday 13 November 1999.

In particular, Lake Superior State University, Sault Sainte Marie, MI, hosted teams from several schools:

Algoma University College, Sault Sainte Marie, Ontario, Canada
Lake Superior State University, Sault Sainte Marie, Michigan, USA
Michigan Technological University, Houghton, Michigan, USA
Northern Michigan University, Marquette, Michigan, USA

The contest consisted of 6 problems to be solved over a 5 hour period. The official solutions have not yet been posted, so what follows are the questions and MY solutions.

Problem 1
Problem 1 Solution (C)
Problem 1 Solution (C++)

Problem 2
Problem 2 Solution (C)
Problem 2 Solution (C++)

Problem 3
Problem 3 Solution (C)
Problem 3 Solution (C++)

Problem 4
Problem 4 Solution (C)
Problem 4 Solution (C++)

Problem 5
Problem 5 Solution (C)
Problem 5 Solution (C++)

Problem 6
Problem 6 Solution (C)
Problem 6 Solution (C++)

For more information, please visit the official contest site.

1999-2000 ACM North Central Regional Programming Contest

1999-2000 ACM North Central Regional Programming Contest

Problem 1 — Gray Codes

 

One description of a Gray code (named after xxx) is that it is a sequence of 2k binary numbers, each having k digits, such that adjacent numbers in the sequence differ in only one digit (or bit position).  For example, consider the case k = 3.  A sequence of eight 3-bit numbers satisfying the requirements is shown in Figure 1, below.  Note that the sequence is cyclic, in that the condition that only a single bit is different between adjacent numbers in the sequence is true when considering the last (1 0 0) and the first (0 0 0) numbers in the sequence.

0

0

0

 

 

 

 

 

0

0

0

0

0

1

 

 

 

 

 

0

0

1

0

1

1

 

 

 

 

 

0

1

0

0

1

0

 

 

 

 

 

0

1

1

1

1

0

 

 

 

 

 

1

0

0

1

1

1

 

 

 

 

 

1

0

1

1

0

1

 

 

 

 

 

1

1

0

1

0

0

 

 

 

 

 

1

1

1

 

 

 

 

 

 

 

 

 

 

 

Figure 1

 

Figure 2

 

Figure 3

A classic application of Gray codes is in sensing the position of a drum attached to a rotating mechanical object.  Imagine that a strip of paper having k bands (three in this example) is prepared and attached to the drum.  Each band is subdivided into 2k colored cells, with a white cell representing a 0 bit in the code, and a black cell representing 1.  The three bands for the case k = 3 would appear as shown in Figure 2.  Associated with each strip is a light sensor that reports 0 when it senses white, and 1 when it senses black.  If the strip is attached to the rotating object, then the sensors report the code (as a 3-bit number) corresponding to the approximate rotational position of the object.  Since only one sensor’s output changes at a time during rotation, there is no possibility that imprecise sensor placement will result in an incorrect rotational position report.

Examining Figure 1 we can better understand this physical interpretation of Gray codes.  Since there are 8 codes corresponding to 360 degrees of rotation, we see that each code corresponds to a 45-degree region.  For example, when the sensors report 000 we know the device is in the 0 to 45 degree region.  When the sensors report 010 we know the device is in the 135 to 180 degree region.

Generating the Gray code shown in Figure 1 begins with the binary equivalent of the numbers 0 to 2k-1 (as shown in Figure 3).  Now transform each of these numbers by replacing each bit (except the leftmost) by its sum (modulo 2) with the preceding (untransformed) bit.  For example, consider the transformation of the number 110.  The leftmost bit is unchanged and remains 1.  The next bit is replaced by the sum of 1 and 1 (modulo 2), which is 0.  The rightmost bit is replaced by the sum of 1 and 0 (modulo 2), which is 1.  This yields the value 101, as shown by the corresponding row of the sequence shown in Figure 1.

In this problem you are to display the particular k-bit binary value in a Gray code sequence corresponding to a particular angle A.  You will be provided with the values of k and A in the input data.  k will be no larger than 32.  A will be an integer in the range 0 to 360, and will never correspond to an angle at which the sensors change.  For the example given above, A will never be a multiple of 45.  Assume that angles increase in the order shown in the example above.  The Gray code value containing only zeroes corresponds to the region with the smallest angles.

Input

There will be multiple test cases in the input, each containing integer values for k and A, in that order.  A pair of zeroes will follow the last test case.

Output

For each input case, display the case number (these are sequential, starting with 1) and the appropriate k-bit binary value.  Separate each bit in the output with a single blank.  The output should appear in the same format as shown in the example below.


Sample Input

3 10

3 350

3 91

0 0

Expected Output

1: 0 0 0

2: 1 0 0

3: 0 1 1

 

1999-2000 ACM North Central Regional Programming Contest

1999-2000 ACM North Central Regional Programming Contest

Problem 2 — Cycles, Period.

 

A scientist is making observations (recorded as integer values) of a process that is believed to be cyclic.  That is, if the period of the process is p, then the process values observed at times 0, p, 2p, … are all the same, as are those values observed at times 1, p+1, 2p+1, …, and so forth.  The scientist also expects that the values that occur in a single cycle are all unique.  That is, if the value observed at time t is st, then for all i and j such that 0 < i < p, 0 < j < p, we expect that si ¹ sj for i ¹ j.

Unfortunately, the scientist cannot continuously observe the process, so observations are made at somewhat random times.  In a log, the scientist records observations as a sequence of pairs of numbers, t and s, where t is the integer elapsed time (since the first observation), and s is the value obtained at that time.  The log is maintained in order of increasing time of the observations.

For example, suppose a particular process goes through a cycle with values of 1, 2, 3, 4 and 5.  If we assume the first observed value (at time t = 0) is 1, then the scientist’s log might contain the following pairs of integers: (0, 1), (3, 4), (6, 2), (8, 4), (12, 3), (21, 2), (25, 1).

The scientist wants to know if the process is cyclic, and if it is, the period p of the process. Your aid has been enlisted.  You are to write a program that uses the data from the log as input, and then reports the cycle period for the process if possible.  If no cycle can be determined (either because insufficient data is provided, or the data doesn’t support the existence of a cycle), then an appropriate message is to be displayed.

The period you are to report is the longest that the data supports.  For the data to support the assumption that the process is cyclic, the following conditions must hold.

If no observed process values are repeated in the log, then you are to assume the process is not cyclic and report that fact.

Input

The input data will contain multiple test cases.  Each test case will consist of an arbitrary number of observations reported as pairs of integers, each pair containing the time of observation and the process value.  Process values will always be greater than zero.  The input for each test case will be terminated with a pair of zeroes, which are not to be treated as data.  An additional pair of zeroes will follow the last test case, effectively representing a test case with no observations, which is not to be processed.

Output

For each test case, determine if the given log data indicates the process is cyclic.  If so, report the longest possible period supported by the data in a form similar to that shown below.  If the log data does not support identification of the process as cyclic, then report that fact, again in a form similar to that shown below.

Sample Input

0 1   3 4   6 2   8 4   12 3   21 2   25 1   0 0

0 1   10 1   20 1   0 0

0 1   10 2   0 0

0 0

 

Expected Output

Case 1: cycle time = 5.

Case 2: cycle time = 10.

Case 3: no cycle time can be determined.

 

1999-2000 ACM North Central Regional Programming Contest

1999-2000 ACM North Central Regional Programming Contest

Problem 3 — Wild Cards

 

The ability to use wild card characters to select file names is common in many operating system command languages.  The mechanism used is as follows:

  1. A set of file names S is given from which file names will be selected.  This is frequently the set of names of files in the current directory.
  2. A pattern P is given that may include zero or more wild card characters.
  3. The pattern P is tested against each file name in S, with those that match the pattern being selected.

Patterns can be formed in different ways depending on the command language.  In MS-DOS, for example, the wild card character ‘?’ will match any single character, and the wild card character ‘*’ will match any sequence of adjacent characters of length 0 or more.  Any other non-blank character will only match itself.  For example, the pattern A?*?X will match file names ABCX, ABCDX, and ABCDEX, but will not match AX or ABX.  The pattern *X* will match any file name that includes an X anywhere, while the pattern ?X* will match any file name with at least two characters that has an X in the second position.  Note that the pattern X**X will match what X*X matches.

In this problem you are to determine which file names in a given set match each of a sequence of patterns that may include the * and ? wild card characters.  These wild card characters are to be interpreted as described in the preceding paragraph.

Input

The input will begin with a set of file names, one per line starting in the first column and ending with the end of line.  File names will include only upper and lower case alphabetic characters and decimal digits.  The case of the alphabetic characters is significant (that is, ‘A’ is not the same as ‘a’).  A line containing a single dollar sign (‘$’) follows the last line of the set of file names.

Following the file names will appear a sequence of patterns, one per line starting in the first column and ending with the end of line.  Patterns will include only upper and lower case alphabetic characters, digits, asterisks (‘*’) and question marks (‘?’).  A line containing a single dollar sign (‘$’) indicates the end of the sequence of patterns.

Each pattern and filename will contain between 1 and 20 characters.

Output

For each pattern, determine which file names in the set are matched.  Display the pattern and the matching file names in a format similar to that shown the sample output below.  Note that the matching file names are to be displayed in the order they appeared in the input.

Sample Input

AX

ABX

ABCX

ABCDX

ABCDEX

ABCDEF

AABBCC

XXXXYXXXXX

$

ABCDEF

ABCDE

A?*?X

*X*

?X*

X*X

X**X

A?C*

A*

AA*

*X*Y*X*

$

 

Expected Output

Case 1. Pattern ABCDEF matches...

   ABCDEF

 

Case 2. Pattern ABCDE matches...

 

Case 3. Pattern A?*?X matches...

   ABCX

   ABCDX

   ABCDEX

 

Case 4. Pattern *X* matches...

   AX

   ABX

   ABCX

   ABCDX

   ABCDEX

   XXXXYXXXXX

 

Case 5. Pattern ?X* matches...

   AX

   XXXXYXXXXX

 

Case 6. Pattern X*X matches...

   XXXXYXXXXX

 

Case 7. Pattern X**X matches...

   XXXXYXXXXX

 

Case 8. Pattern A?C* matches...

   ABCX

   ABCDX

   ABCDEX

   ABCDEF

 

Case 9. Pattern A* matches...

   AX

   ABX

   ABCX

   ABCDX

   ABCDEX

   ABCDEF

   AABBCC

 

Case 10. Pattern AA* matches...

   AABBCC

 

Case 11. Pattern *X*Y*X* matches...

   XXXXYXXXXX

 

1999-2000 ACM North Central Regional Programming Contest

1999-2000 ACM North Central Regional Programming Contest

Problem 4 — Clock Angles

 

The angle between the hour and minute hands of an analog clock is always between 0 and 180 degrees, inclusive.  For example, at 12:00 the angle between the hands is 0 degrees.  At 6:00 the angle is 180 degrees, and at 3:00 the angle is 90 degrees.  In this problem you are to find the angle between the hands of a clock for an arbitrary time between 12:00 and 11:59.

Input

The input data will contain multiple test cases.  Each test case will consist of two numbers.  The first number specifies the hour, and will be greater than 0 and less than or equal to 12.  The second number specifies the number of minutes, and will be in the range 0 to 59.  Two numbers, each of which is 0, will follow the last test case.

Output

For each test case, display the time in the usual form and the smallest angle formed by the hands, accurate to one fractional digit.  The output should be similar to that shown in the sample below.

Sample Input

12 0

12 30

6 0

3 0

0 0

 

Expected Output

At 12:00 the angle is 0.0 degrees.

At 12:30 the angle is 165.0 degrees.

At 6:00 the angle is 180.0 degrees.

At 3:00 the angle is 90.0 degrees.

 

1999-2000 ACM North Central Regional Programming Contest

1999-2000 ACM North Central Regional Programming Contest

Problem 5 — Going Down!

 

Every positive integer n can be expressed as the sum of one or more non-increasing sequences of one or more positive integers, each less than or equal to n.  For example, the integer 4 can be expressed as 1 + 1 + 1 + 1, or 2 + 1 + 1, or 2 + 2, or 3 + 1, or 4.  In this problem you are determine the number of sequences that meet this requirement for a particular values of n, and also have exactly k terms.  For example, with n = 4 and k = 2, there are two sequences that meet the criteria: 2 + 2 and 3 + 1.  Note that 1 + 3 does not satisfy the requirements of the problem, as the sequence in that case is not non-increasing.

Input

There will be multiple test cases.  For each test case the input will contain values for n and k.  A pair of zeroes will follow the last test case.  The value of n will always be at least 1 and no larger than 100.  The value of k will be at least 1 and no larger than n.

Output

For each test case, print a line containing the case number; these are numbered sequentially, starting with 1.  Then display the number of non-increasing sequences including exactly k integers with sums equal to n, including the values of k and n.  The grammar of your response should be correct!  The example output shown below illustrates an acceptable format.

Sample Input

5 2

5 1

2 2

0 0

Expected Output

Case 1: 2 non-increasing sequences with 2 integers have 5 as their sum.

Case 2: One non-increasing sequence with one integer has 5 as its sum.

Case 3: One non-increasing sequence with 2 integers has 2 as its sum.

 

1999-2000 ACM North Central Regional Programming Contest

1999-2000 ACM North Central Regional Programming Contest

Problem 6 — Hamming It Up

 

If we wish to devise an information encoding scheme that permits us to detect errors, we need to add redundant information.  Consider, for example, that we want to send one of four possible messages over a communication channel.  Digitally, the most obvious way to do this is to associate the four binary codewords 00, 01, 10, and 11 with the four messages, and then send the appropriate codeword over the channel.

But what happens if noise or electrical problems during transmission cause one of the bits in a codeword to be changed?  For example, suppose we sent the codeword 00 but it was received as 01.  Is there any way the receiver of the codeword 01 can detect that it was really supposed to be 00?

R. W. Hamming, almost half a century ago, studied this problem.  One measure of the ability of a set of codewords to support reliable communication is the Hamming distance of the set.  The Hamming distance between any two codewords is the number of bit positions in which the codewords differ.  For example, the codewords 10010 and 11000 differ in two bit positions (the second and fourth bits from the left), so the Hamming distance between them is 2.  The Hamming distance of a set of codewords is just the minimum Hamming distance between any two codewords in the set.  The Hamming distance for the set of codewords including 10010, 11000, and 11111 set would be 2 (since the Hamming distance between 10010 and 11111 is 3, and the Hamming distance between 11000 and 11111 is also 3).  The Hamming distance of our original set of two-bit codewords 00, 01, 10, and 11 is 1, insufficient to even detect a 1-bit error.

In this problem you are to determine the Hamming distance for each of several sets of codewords.  Each codeword in a set will be assumed to be 32 bits long, but will be represented in the input data as a signed decimal integer.  For example, the set of codewords 00, 01, 10, and 11 (assuming a suitable number of leading zero bits) would be specified as 0, 1, 2 and 3 respectively.  Likewise, the codewords 10010, 11000, and 11111 would be specified as 18, 24, and 31 respectively.  If an input decimal integer is negative, then the corresponding codeword is the binary two’s complement representation of the number. There will be no more than 20 codewords in any set. 

Input

There will be multiple test cases in the input.  Each test case begins with an integer n (2 £ n £ 20) specifying the number of codewords in the set.  This is followed by n signed decimal integers giving the value of the codewords.  A single 0 will follow the last test case.

Output

For each input case, display the case number (these are sequential, starting with 1) and the Hamming distance for the set of codewords in that test case.  Display the results in a format similar to that shown below.

Sample Input

4 0 1 2 3

3 18 24 31

2 1 –1

2 0 -1

0

 

Expected Output

Case 1.  Hamming distance = 1.

Case 2.  Hamming distance = 2.

Case 3.  Hamming distance = 31.

Case 4.  Hamming distance = 32.

 

Problem 1

Problem 1—Double Trouble

 

The secret service of Hudonia has always had a strong appetite for strange numbers. This appetite seemed strongest when Hudonia was in trouble. The numbers they were looking for had the following property. Whenever you would right-rotate the number (that is, take away the last digit and put it in front of the number), you would end up with double the original number. Numbers possessing this property were called double-trouble numbers. For example, X = 421052631578947368 is a double-trouble number, since 2X = 842105263157894736 which is a right rotation of X.

The number X is a double-trouble number in the number system with base 10. Any number system with base p ≥ 2, however, has many such double-trouble numbers. In the binary number system (base p = 2), for example, we have the double-trouble numbers 01 and 0101. Notice that the leading zeros are necessary here in order to obtain the proper number after right rotation.

 

The secret service seemed to like the smallest double-trouble numbers in a number system most. For example, in the binary number system the smallest double-trouble number is 01. In the decimal (p = 10) number system, the smallest double-trouble number is 052631578947368421. Being a patriotic Hudonian, you are asked to write a program that computes for a given base p of a number system the smallest double-trouble number in that system.

 

INPUT SPECIFICATION.  The input file will contain a series of integers inclusively between 2 and 200 corresponding to the base for which you are to compute the smallest double-trouble number.  The last number in the file will be 0, signifying the end of input.  Each number will be followed by <EOLN>.  There will be no additional spaces or <EOLN>'s in the file.

 

OUTPUT SPECIFICATION.  The output cases should be processed in the order in which they appear in the input file.  For each input case, print out the smallest double-trouble number for that base using the exact format demonstrated below.  Notice that since it is difficult to express digits for bases greater than 10, we instead use for each digit the decimal number corresponding to that digit followed by a space.  Make sure that the introductory line to each answer is exactly as demonstrated.  Each output case should be followed by an extra <EOLN> character.

 

SAMPLE INPUT.

 

2<EOLN>

10<EOLN>

35<EOLN>

0<EOLN>

<EOF>

 

SAMPLE OUTPUT.

 

For·base·2·the·double-trouble·number·is<EOLN>

0·1·<EOLN>

<EOLN>

For·base·10·the·double-trouble·number·is<EOLN>

0·5·2·6·3·1·5·7·8·9·4·7·3·6·8·4·2·1·<EOLN>

<EOLN>

For·base·35·the·double-trouble·number·is<EOLN>

11·23·<EOLN>

<EOLN>

<EOF>

Problem 2

Problem 2—M*A*S*H

 

Corporal Klinger is a member of the 4077th. Mobile Army Surgical Hospital in the Korean War; and he will do just about anything to get out.  The U.S. Army has made an offer for a lottery that will select one lucky person to return to the USA for a recruiting tour.  Klinger needs your help getting out.

 

The lottery is run by lining up all the members of the unit at attention and eliminating members by having the members “count off:”  the first person in line shouts “1”.  The next person shouts “2”, and so forth, until one person shouts N where N is a number chosen by pulling cards off of the top of a deck. Every time N is reached, the person who shouted it falls out of the line, and counting begins again at 1 with the next person in line. Whenever the end of the line has been reached before a count has been completed, the first person in line shouts out the number just after the one shouted by the last person in line, and the count resumes.  When there is just one person left in the line, that person gets to go to the USA.

 

As the company clerk, Klinger knows what the cards in the deck will be.  He can also order the recruits to stand in any order he chooses, and he can place himself in any position he cares to.  Klinger's problem is that even with all this information, he still doesn't know where he should be to guarantee his return home.  Your program should solve this problem for him.

 

INPUT SPECIFICATION.  The input file will contain multiple test cases.  Each test case will consist of two lines.  The first line will consist of a decimal integer N inclusively between 1 and 100 followed by <EOLN>.  N represents the number of people in line.  The second line will contain N–1 integers inclusively between 1 and 100 corresponding to the cards in the deck in the order in which they will be called.  The numbers will be separated by exactly one space and the line will be terminated by <EOLN>.  0<EOLN> will follow the last test case in the file.  No extra spaces or <EOLN>'s will appear in the file.

 

OUTPUT SPECIFICATION.  The output cases should be processed in the order in which they appear in the input file.  For each case, print “Klinger should be in position #N.” where N is the correct answer.  Each line should be terminated by <EOLN>.  No extra <EOLN> should appear in the output file.

 

SAMPLE INPUT.

 

10<EOLN>

3·2·5·4·4·3·5·5·4<EOLN>

10<EOLN>

10·9·8·7·6·5·4·3·2<EOLN>

0<EOLN>

<EOF>

 

SAMPLE OUTPUT.

 

Klinger·should·be·in·position·#4.<EOLN>

Klinger·should·be·in·position·#1.<EOLN>

<EOF>

Problem 3

Problem 3—Interpreting Control Characters

 

Virtually all text-mode terminals are special-purpose computer systems, including a serial port (for communication with a modem or another computer system), a keyboard, a CRT, and of course, a microprocessor, some RAM, and a control program in ROM.  When a character arrives at the terminal, either from the keyboard or the serial port, the terminal's software classifies it as either a display character (which is to be displayed on the CRT) or as a character that introduces a control sequence. A control sequence is used to direct the terminal to do such things as clear the screen, move the cursor in a specified manner, or perhaps change fonts.

 

In this problem assume you are writing the software for a small terminal with a 10-row, 10-column display (perhaps for a point-of-sale terminal).  Rows and columns are numbered 0 through 9.  The character that introduces a control sequence is the circumflex.  The character (or in one case, the two characters) immediately following the control sequence introducer will direct your software in performing its special functions.  Here is the complete list of control sequences you will need to interpret:

 

^b:  Move the cursor to the beginning of the current line; the cursor row does not change

^c:  Clear the entire screen; the cursor row and column do not change

^d:  Move the cursor down one row if possible; the cursor column does not change

^e:  Erase characters to the right of, and including, the cursor column on the cursor's row; the cursor row and column do not change

^h:  Move the cursor to row 0, column 0; the image on the screen is not changed

^i:  Enter insert mode (see below)

^l:  Move the cursor left one column, if possible; the cursor row does not change

^o:  Enter overwrite mode (see below)

^r:  Move the cursor right one column, if possible; the cursor row does not change

^u:  Move the cursor up one row, if possible; the cursor column does not change

^^:  Write a circumflex at the current cursor location exactly as if it was not a special character; this is subject to the actions of the current mode (insert or overwrite)

^##:  Move the cursor to the row and column specified; # represents a decimal digit; the first # represents the new row number, and the second # represents the new column number.

 

No illegal control sequences will ever be sent to the terminal. The cursor cannot move outside the allowed screen locations (that is, between row 0, column 0 and row 9, column 9).  When a normal character (not part of a control sequence) arrives at the terminal, it is displayed on the terminal screen in a manner that depends on the terminal mode. When the terminal is in overwrite mode (as it is when it is first turned on), the received character replaces the character at the cursor's location. But when the terminal is in insert mode, the characters to the right of and including the cursor's location are shifted right one column, and the new character is placed at the cursor's location; the character previously in the rightmost column of the cursor's row is lost. Regardless of the mode, the cursor is moved right one column, if possible.

 

INPUT SPECIFICATION.  The input will contain multiple tests of your terminal software.  Each test begins with a line containing an integer N followed by <EOLN>.  Following this line there will be N more lines of data, each character of which is to be treated as if it was input, in the order read, to your terminal software.  <EOLN> characters in the input are to be ignored, but spaces in the input data are normal characters to be displayed on your terminal.  The last test will be followed by a single line containing 0<EOLN>.  No control sequence will be split between two lines of the input data.  No extra <EOLN> will appear in the input file.  At the beginning of each test case you are to assume the terminal screen is clear (that is, filled with spaces), that the terminal is in overwrite mode, and that the cursor is in row 0, column 0 of the screen.

 

OUTPUT SPECIFICATION.  The output cases should be processed in the order in which they appear in the input file.  For each case, output the word “Case” followed by a space followed by the case number (these are numbered sequentially starting with 1) followed by <EOLN> and the screen image the way it would look at the end of processing the data in the test case. Enclose the screen image in a “box;” see the sample below for illustration of the required format.

 

SAMPLE INPUT.

 

7<EOLN>

This·is·bad^h^c<EOLN>

^05^^<EOLN>

^14/·\^d^b···/···\<EOLN>

^u^d^d^l^l^l^l^l^l^l^l^l<EOLN>

^r^r<·ACM·>^l^l^d/^b···\<EOLN>

^b^d····\·/<EOLN>

^d^l^lv<EOLN>

7<EOLN>

^i9^l8^l7^l6^l5^l4^l3^l2^l1^l0<EOLN>

^o^d^lThis·is·#1^d^bThis·is·#2<EOLN>

^d^bThis·is·#3^d^bThis·is·#4<EOLN>

^d^bThis·is·#5^d^bThis·is·#6<EOLN>

^d^bThis·is·#7^d^bThis·is·#8<EOLN>

^i^d^bThis·is·#9^d^bThis·is·#10<EOLN>

^54^e·Hello^d^l^l^l^lWorld<EOLN>

0<EOLN>

<EOF>

 

SAMPLE OUTPUT.

 

Case·1<EOLN>

+----------+<EOLN>

|·····^····|<EOLN>

|····/·\···|<EOLN>

|···/···\··|<EOLN>

|··<·ACM·>·|<EOLN>

|···\···/··|<EOLN>

|····\·/···|<EOLN>

|·····v····|<EOLN>

|··········|<EOLN>

|··········|<EOLN>

|··········|<EOLN>

+----------+<EOLN>

Case·2<EOLN>

+----------+<EOLN>

|0123456789|<EOLN>

|This·is·#1|<EOLN>

|This·is·#2|<EOLN>

|This·is·#3|<EOLN>

|This·is·#4|<EOLN>

|This·Hello|<EOLN>

|This·World|<EOLN>

|This·is·#7|<EOLN>

|This·is·#8|<EOLN>

|This·is·#0|<EOLN>

+----------+<EOLN>

<EOF>

Problem 4

Problem 4—OOPS

 

You've been sitting in front of the terminal for three hours savagely coding the Assembler assignment that's due tomorrow.  Your best friend, who finished the program last week and has been rubbing it in for just as long, saunters up to your terminal and offers, "Coke break, slow poke?"  You take the Coke he hands you and you lean your head back, savoring the refreshing feeling of the drink as it soothes your parched throat; too much coding always made your throat raw.  “Hey, can I look at how far you've gotten?” your friend asks.  “Sure,” you reply, taking another long drink. As you're enjoying your drink and thinking of what “The Real Thing” really is, you hear a whispered “oops” from the direction of your terminal.  “What?!” you demand.  Your friend replies, backing away, “I think I just deleted your source code.”

 

“Arrrgggghhh!” you spurt as your friend runs from the computer lab, mumbling prayers for divine protection.  You double-check and—sure enough—all you have left of your precious Assembler assignment is the executable code from your last compile.  And you were so close to finishing!  Do you take a zero?  No, that last test was a killer.  Start over? NOT!  Instead, your hands fumble for your Assembler textbook.  Ah, here we go: a description of the encoding scheme used by the computer's assembler.  It doesn't look too bad and you remember most of the hand disassembling you did in class! It's decided then, you'll just have to write a quick disassembler to convert the executable code back into your source code so that you can finish your assignment before Survivor comes on.  You open your textbook and begin reading:

 

Instruction Set

HEX Code        Instruction

 

0                      ADD arg,arg

1                      SUB arg,arg

2                      MUL arg,arg

3                      DIV arg,arg

4                      MOV arg,arg

5                      BREQ arg

6                      BRLE arg

7                      BRLS arg

8                      BRGE arg

9                      BRGR arg

A                      BRNE arg

B                      BR arg

C                      AND arg,arg,arg

D                      OR arg,arg,arg

E                      XOR arg,arg,arg

F                      NOT arg

 

 

ADD arg,arg means that the ADD instruction takes two arguments.

Opcodes are 4 bytes in length. An operand is made up of two fields: a mode and a value. The mode is two bits and the value is fourteen bits for a total of sixteen bits. The possible values for mode are: 00: register; 01: absolute; 10: PC-relative; 11: constant

 

The value field for a register operand specifies the number of the register. For example, if the value field contained a seven then that would specify register number 7, written "R7".  The value field for an absolute operand specifies the absolute address that the operand is to be stored at. For example, if the value field contained the number 110, that would denote address location 110, which is written "$110".  The value field for a PC-Relative operand specifies the offset of the address relative to the program counter. (On this computer, all PC-relative offsets are non-negative). For example, if the value field contained the number 45, that would specify the address location (Program Counter) + 45, which is written "PC+45".  The value field for a constant operand specifies a constant.  For example, if the value field contained the number 1276, then that would specify the actual number 1276 and is written as "1276".

 

INPUT SPECIFICATION.  The input file will contain a series of hexadecimal digits (0-F) corresponding to a compiled program.  There will be exactly 30 digits on each line, except for the last line which might contain fewer.  Each line is terminated by <EOLN>.  An extra <EOLN> (a blank line) will signal the end of the input.  There will be no additional spaces or <EOLN>'s in the file, but it is certainly possible that an <EOLN> will occur between the bytes of an individual command.  All commands in the input file will be valid.

 

OUTPUT SPECIFICATION.  The output files should contain the assembler commands corresponding to the hex code in the input file.  There should be one space between the command and its arguments and one comma between successive arguments to a command.  There should be one <EOLN> character following the final argument of a command.  No extra spaces or <EOLN>s beyond these should appear in the output file.

 

SAMPLE INPUT.

 

4C00D00004C0020001000000001400<EOLN>

005FFFB801E<EOLN>

<EOLN>

<EOF>

 

SAMPLE OUTPUT.

 

MOV·13,R0<EOLN>

MOV·2,R1<EOLN>

ADD·R0,R1<EOLN>

MOV·R0,$8191<EOLN>

BR·PC+30<EOLN>

<EOF>

Problem 5

Problem 5—Haiku

 

Haiku is an ancient form of Japanese poetry.  A haiku is a three-line poem with seventeen syllables, where the first line must contain five syllables, the second line must contain seven syllables, and the third line must contain five syllables.  The lines do not have to rhyme.  Here is an example, where slashes separate the lines:

 

Computer programs/The bugs try to eat my code/I must not let them.

 

You must write a program that will review a haiku and check that each line contains the correct number of syllables.

 

INPUT SPECIFICATION.  The input contains one or more lines, each of which contains a single haiku.  A haiku will contain at least three words, and words will be separated by either a single space or one slash.  Slashes also separate the three lines of a haiku, so each haiku will contain exactly two slashes.  (The three lines of the haiku will be contained within one physical line of the file.)  A haiku will contain only lowercase letters (a-z), forward slashes (/), and spaces, and will be no more than 200 characters long (not counting the <EOLN> that terminates the line).  The last of line of the file is “e/o/i<EOLN>”.  This line is not to be processed; it only signals the end of input.  Each haiku is guaranteed to contain three lines, and each line will contain at least one word.  Your job is to determine whether each line has the correct number of syllables (5/7/5).  For the purposes of this problem, every contiguous sequence of one or more vowels counts as one syllable, where the vowels are a, e, i, o, u, and y. Every word will contain at least one syllable.  (Note that this method of counting syllables does not always agree with English conventions. In the example above, your program must consider the word code to have two syllables because the o and the e are not consecutive. However, in English the e is silent and so code actually has only one syllable.)

 

OUTPUT SPECIFICATION.  For each haiku, output a single line that contains 1 if the first line has the wrong number of syllables, 2 if the second line has the wrong number of syllables, 3 if the third line has the wrong number of syllables, or Y if all three lines have the correct number of syllables.  If the haiku is not correct, you must output the number of the first line that has the wrong number of syllables.  All lines are terminated with <EOLN>.

 

SAMPLE INPUT.

 

happy·purple·frog/eating·bugs·in·the·marshes/get·indigestion<EOLN>

computer·programs/the·bugs·try·to·eat·my·code/i·will·not·let·them<EOLN>

a·e·i·o·u/this·is·seven·syllables/a·e·i·o·u·y<EOLN>

e/o/i<EOLN>

<EOF>

 

SAMPLE OUTPUT.

 

Y<EOLN>

2<EOLN>

3<EOLN>

<EOF>

Problem 6

Problem 6—The Sultan's Successors

 

The Sultan of Nubia has no children, so she has decided that the country will be split into up to k separate parts on her death and each part will be inherited by whoever performs best at some test. It is possible for any individual to inherit more than one or indeed all of the portions. To ensure that only highly intelligent people eventually become her successors, the Sultan has devised an ingenious test. In a large hall filled with the splash of fountains and the delicate scent of incense have been placed k chessboards. Each chessboard has numbers in the range 0 to 10000 written on each square and is supplied with 8 jewelled chess queens. The task facing each potential successor is to place the 8 queens on the chess board in such a way that no queen threatens another one, and so that the numbers on the squares thus selected sum to a number at least as high as one already chosen by the Sultan. (For those unfamiliar with the rules of chess, this implies that each row and column of the board contains exactly one queen, and each diagonal contains no more than one.)

Write a program that will read in the number and details of the chessboards and determine the highest scores possible for each board under these conditions. (You know that the Sultan is both a good chess player and a good mathematician and you suspect that her score is the best attainable.)

 

INPUT SPECIFICATION.  The input file will begin with a decimal integer k inclusively between 1 and 10000 followed by <EOLN>, indicating the number of chessboards that will follow.  Each chessboard will consist of 8 rows of 8 decimal integers inclusively between 1 and 10000 corresponding to the values of the squares.  There will be exactly one space between integers on each line, and each line will be terminated by <EOLN>.  There may or may not be one or more additional <EOLN>'s before, after, or between chessboards, but no extra space or <EOLN> will appear in the input file beyond what is specified above.

 

OUTPUT SPECIFICATION.  The output cases should be processed in the order in which they appear in the input file.  For each input case, the output file should contain the decimal integer corresponding to the sum of the values on the squares on which the queens should be placed.  Each integer should be followed by exactly one <EOLN>.

 

SAMPLE INPUT.

 

2<EOLN>

1·2·3·4·5·6·7·8<EOLN>

9·10·11·12·13·14·15·16<EOLN>

17·18·19·20·21·22·23·24<EOLN>

25·26·27·28·20·30·31·32<EOLN>

33·34·35·36·37·38·39·40<EOLN>

41·42·43·44·45·46·47·48<EOLN>

49·50·51·52·53·54·55·56<EOLN>

57·58·59·60·61·62·63·64<EOLN>

<EOLN>

0·0·0·0·0·0·0·0<EOLN>

0·0·0·0·0·0·0·0<EOLN>

0·0·0·0·0·0·0·0<EOLN>

0·0·0·0·0·0·0·0<EOLN>

0·0·0·0·0·0·0·0<EOLN>

0·0·0·0·0·0·0·0<EOLN>

0·0·0·0·0·0·0·0<EOLN>

0·0·0·0·0·0·0·0<EOLN>

<EOF>

SAMPLE OUTPUT.

 

260<EOLN>

0<EOLN>

<EOF>

2001 ACM PRACTICE CONTEST

The 2001 NMU ACM Practice Contest was held from 1:00 to 6:00 P.M. EDT on Saturday 20 October 2001 at Northern Michigan University. The contest was attended by 4 teams. The original purpose of the contest is to determine which two teams from NMU will attend the North Central North America ACM Regional Programming Contest this year as well as to provide our teams with practice. However, since a rule change allows for an unlimited number of competing teams, this contest served as practice only.

The teams were as follows:

Competing:

A--?
B--?
HOBOS WITH GUNS--Russ Langkawel, Joe Schmeltzer, Carey Stortz
MYSTIC SUCCESS--Rocco Carello, Dan Crosscup, Bryan Langer
SUCKS AT CHESS--Bob Lindquist, Dave Porta, John Wilson

The contest consisted of 6 problems to be solved over a 5 hour period.

Below is the list of problems, test input files, correct output files, and sample solutions. There were many ways to solve the problems, of course. These solutions were developed using the C compiler of DJGPP (the Gnu C Compiler for Windows).

Problem 1
Problem 1 Input File
Problem 1 Output File
Problem 1 Solution

Problem 2
Problem 2 Input File
Problem 2 Output File
Problem 2 Solution

Problem 3
Problem 3 Input File
Problem 3 Output File
Problem 3 Solution

Problem 4
Problem 4 Input File
Problem 4 Output File
Problem 4 Solution

Problem 5
Problem 5 Input File
Problem 5 Output File
Problem 5 Solution

Problem 6
Problem 6 Input File
Problem 6 Output File
Problem 6 Solution

Here are the complete results. Congratulations to Mystic Success for winning the Practice Contest.

NMU INVITATIONAL PROGRAMMING CONTEST #1

The first annual NMU Invitational Programming Contest was held from 12:00 to 5:00 P.M. EST on Saturday 1 April 2000 at Northern Michigan University. The contest was organized by the NMU student chapter of the ACM and was attended by a total of 16 teams from the following schools.

Lake Superior State University, Sault Sainte Marie, Michigan, USA
Michigan Technological University, Houghton, Michigan, USA
Northern Michigan University, Marquette, Michigan, USA
The University of Michigan--Flint, Flint, Michigan, USA

The contest consisted of 6 problems to be solved over a 5 hour period.

Here is the list of rules and problems.

Below is the list of test input files, correct output files, and sample solutions. There were many ways to solve the problems, of course. These solutions were developed using the Gnu C Compiler on Red Hat Linux.

Problem 1 Input File
Problem 1 Output File
Problem 1 Solution

Problem 2 Input File
Problem 2 Output File
Problem 2 Solution

Problem 3 Input File
Problem 3 Output File
Problem 3 Solution

Problem 4 Input File
Problem 4 Output File
Problem 4 Solution

Problem 5 Input File
Problem 5 Output File
Problem 5 Solution

Problem 6 Input File
Problem 6 Output File
Problem 6 Solution

The "Seg Faults" from Michigan Tech won the competition.
Second place went to "W" from Michigan Tech.
Third place went to "Illiana Connection" from NMU.

Here are the complete results. NMU INVITATIONAL PROGRAMMING CONTEST #2

The second annual NMU Invitational Programming Contest was held from 1:00 to 6:00 P.M. EST on Saturday 31 March 2001 at Northern Michigan University. The contest was organized by the NMU student chapter of the ACM and was attended by a total of 21 teams from the following schools.

Algoma University College, Sault Sainte Marie, Ontario, Canada
Lake Superior State University, Sault Sainte Marie, Michigan, USA
Michigan Technological University, Houghton, Michigan, USA
Northern Michigan University, Marquette, Michigan, USA
The University of Michigan--Flint, Flint, Michigan, USA

The contest consisted of 6 problems to be solved over a 5 hour period.

Here is the list of rules.

Below is the list of problems, test input files, correct output files, and sample solutions. There were many ways to solve the problems, of course. These solutions were written in ANSI C, and should compile on any C/C++ compiler.

Problem 1
Problem 1 Input File
Problem 1 Output File
Problem 1 Solution

Problem 2
Problem 2 Input File
Problem 2 Output File
Problem 2 Solution

Problem 3
Problem 3 Input File
Problem 3 Output File
Problem 3 Solution

Problem 4
Problem 4 Input File
Problem 4 Output File
Problem 4 Solution

Problem 5
Problem 5 Input File
Problem 5 Output File
Problem 5 Solution

Problem 6
Problem 6 Input File
Problem 6 Output File
Problem 6 Solution

NMU TEAM DENNY won the competition.
Second place went to FLINT 1.
Third place went to ALGOMA A.

Here are the complete results. How to Reach Me

Home:

ANDREW A POE
1400 W FAIR AVE APT 3
MARQUETTE MI 49855-2672
UNITED STATES OF AMERICA
+1 906 226-7534

Office:

ANDREW A POE, ASSISTANT PROFESSOR
DEPARTMENT OF MATHEMATICS AND COMPUTER SCIENCE
NORTHERN MICHIGAN UNIVERSITY
1401 PRESQUE ISLE AVE
MARQUETTE MI 49855-5340
UNITED STATES OF AMERICA
+1 906 227-1598
+1 906 227-2010 (FAX)
apoe@nmu.edu

My Education

My degrees and certificates are as follows:

Maine-Endwell Central School District, Endwell, New York, USA
M-E Senior High School
Diploma
SUCCESSFUL COMPLETION OF REGENTS EXAMINATION WITH HONOR
MERIT
NATIONAL HONOR SOCIETY
1985

Cornell University, Ithaca, NY, USA
College of Arts and Sciences
Bachelor of Arts
Magna Cum Laude in Mathematics
Cum Laude in Computer Science
and With Distinction in All Subjects
1989

The University of Michigan, Ann Arbor, MI, USA
The Horace H. Rackham School of Graduate Studies
Master of Science
(Mathematics)
1991

The University of Michigan, Ann Arbor, MI, USA
The Horace H. Rackham School of Graduate Studies
Master of Science
(Computer Science & Engineering)
1994

The University of Michigan, Ann Arbor, MI, USA
Horace H. Rackham School of Graduate Studies
Candidate in Philosophy
Computer Science & Engineering
1995

The University of Michigan, Ann Arbor, MI, USA
The Horace H. Rackham School of Graduate Studies
Doctor of Philosophy
(Computer Science and Engineering)
1999

Andrew Alan Poe

I am Andy Poe. I am an Assistant Professor in the Department of Mathematics and Computer Science at Northern Michigan University in Marquette, Michigan, USA.

Here are some facts about me

My Education

I have been involved in a project for the last few years developing graph-partitioning software known as BHS.

Here are links to the courses I am teaching:

FALL 2002

CS 126-01
CS 228-01
CS 326-01
CS 495-03
CS 498-02
CS 498-03

I also coach the programming teams at NMU. We participate in the ACM North Central North American Regional Programming Contest held every Fall at Lake Superior State University in Sault Ste. Marie, Michigan, USA and in a competition hosted by NMU every spring. Here are some contest problems and solutions:
1999 ACM Programming Contest
2000 ACM Programming Contest
2001 ACM Programming Contest
NMU Programming Contest #1
NMU Programming Contest #2
NMU Programming Contest #3
2000 NMU ACM Practice Contest
2001 NMU ACM Practice Contest
Other interesting problems
Java Solutions for some problems

Contacting me

Choral Affiliations

I am an amateur singer and have been involved in choral groups since I was very young. My voice part is deep bass and it has been since I started college. However, I have had the great pleasure of singing Soprano, Alto, Tenor, and Baritone at other times in my life as I worked my way down. I have never not sung since I began the second grade! In fact, it's the only hobby I never eventually lost interest in (professional interests excluded)!

In particular, I have taken a strong interest in a cappella singing, which is choral singing without any instrumental accompaniment. I have sung in a number of a cappella groups and have also collected a number of a cappella compact discs and cassettes from professional, amateur, and collegiate a cappella groups.

The a cappella groups of which I have been a member are as follows:

Drastic Measures, 1987
The Class Notes, 1987-9
Amazin' Blue, 1989-94
Desperate Measures, 1994-8
The Vocal Arts Ensemble, 1998-9

The accompanied groups that have had the pleasure of my membership are:

The Silver Springs First United Methodist Church Junior Choir, 1975-80
The Silver Springs Elementary School Chorus, 1976-8
The Letchworth Central School 5th. and 6th. Grade Chorus, 1978-80
The Endwell United Methodist Church Junior Choir, 1980-2
The Endwell United Methodist Church Senior Choir, 1982-5
The Maine-Endwell Senior High School Chorus, 1981-5
The Cornell University Glee Club, 1985-9
The Cornell University Chorale, 1987
The University of Michigan Arts Chorale, 1989-92
The University of Michigan Choral Union, 1992
The First Presbyterian Church of Ypsilanti Senior Choir, 1995-9 The First Presbyterian Church of Marquette Senior Choir, 1999- The Marquette Choral Society, 1999-

Drastic Measures

Drastic Measures was a mixed-voice a cappella group at Cornell University. It formed in 1986 and its goal was to provide clean, inoffensive a cappella music to a campus riddled with vice and sin. Kind of like evangelical a cappella except absolutely secular. I sang with them only one semester, Fall 1987, and then jumped ship to join the Class Notes. Drastic Measures broke up shortly thereafter.

The Class Notes

I was not accepted to the Class Notes until my third audition, at the tail end of the Fall 1987 semester. I stayed with the Notes until I graduated in 1989. Mixed-voice collegiate a cappella was somewhat rare in the USA even as late as the 1980's. The scene was strongly dominated by male groups. The Class Notes was the strongest of the mixed-voice groups at Cornell, and, having been founded in 1983, was the oldest mixed-voice a cappella group still in existence there. (The Cornellaires, from the 1950's, was the absolute oldest group I could find record of, but they were long since defunct.)

The biggest highlight of my career with the Class Notes was our performance at the Cornell Jamboree in the Fall 1988 semester. Our director was a tough-as-nails son-of-a-gun named Stuart Piltch who worked us until we were hoarse. However, at Cornell Jamboree that year, we outperformed the other groups by a margin wide enough that there was little debate on the issue. As a result, auditions to the Class Notes began increasing noticeably. The Notes were also trying to build a reputation of approachability, of not being campus snobs. It was successful to an extent, though not completely, and it got harder to stay on positive terms with all our fans when they began auditioning in droves and the vast majority had to be turned away.

I made a lot of friends in the Notes, several of which I still keep in touch. However, I was growing tired of Cornell. My years there were fantastic, and I would never trade them, but I needed to move on. Cornell, it seemed to me at the time, was dominated by New England haute couture, and I was an Upstate hick. On weekends, my friends in the Notes wanted to hit clubs and drink champagne, and I wanted to watch Star Trek with pizza and coke. Now, college students everywhere like to party on the weekends--this is not a function of location--but this was not my impression at the time. I felt that aside from the music--which I adored--I had precious little in common with these people, and although I loved them on a personal level, I wanted to continue my education in a place less Ivy League. Although I was accepted by my first choice, The University of California--Berkeley, I ended up declining their invitation due to a bureaucracy so incompetent as to be (in my mind) criminal. My second choice, The University of Michigan, also accepted me and they then became my first choice, so off I went.

The Class Notes are still going strong at Cornell. You can see their web page here.

Amazin' Blue

Amazin' Blue is, by any objective measure, the best thing of which I was ever a member. In a scant two years from the time I joined, Amazin' Blue rose from an obscure group to one of the definitive mixed-voice collegiate a cappella groups in the USA. I auditioned in the Fall 1989 semester, just after I arrived at The University of Michigan. Ten members had resigned at the end of the previous semester, including every single man, so there were openings aplenty, and I was accepted. Although my initial views about Amazin' Blue were negative, my opinion did a 180 before that semester reached completion. The group decided to cut an album that semester. I voted no, on the grounds that an album takes a lot of time, and we had ten new members giving us a sound with which none of us were familiar. I was voted down, fortunately, since that album forced us to meld our voices together. The result was staggering, and had ramifications far beyond a simple album: we had a solid sound, AND we had a membership consisting of a cappella hobbyists. You see, a cappella was not that big in the midwest at that time (in fact, Amazin' Blue is partly responsible for its popularity here now), and most of the local groups had no vision past the end of their nose. So, when other groups performed largely 1950's doo-wop at the University of Michigan's Monsters of A Cappella Concert in the Winter 1991 semester, Amazin' Blue performed songs like "Psycho Killer," "Love Shack," and "Schoolhouse Rock Medley." The result was staggering, for Amazin' Blue, anyway. The audience of that show, many of which had never even heard of us, suddenly made Amazin' Blue a campus favorite.

Later that same semester, Amazin' Blue made a trip to Washington University in St. Louis to perform with some groups there. The musical circles there were of the opinion that mixed-voice a cappella was ultimately unviable. Shortly after we performed, two mixed-voice a cappella groups formed. When Amazin' Blue returned to Wash U. three years later (I was the only member to perform at Wash U. both times), we were greeted with a huge ovation just from the announcement, "Ladies and gentlemen, Amazin' Blue," an ovation rivaling those from our own home crowd!

It was this semester as well that Amazin' Blue released Coed Naked A Cappella, an album that won us a national award as the best mixed-voice collegiate a cappella album of the year. Keep in mind that previously, no one had heard of Amazin' Blue. We were building our own reputation here, and it felt real good. The auditions we had at the beginning of the Fall 1991 term brought us a lot of solid new members, and, as a result, our concert that semester was the best Amazin' Blue show of which I was a performer.

I should have left the group at that time, on a musical and emotional high note. However, I still wanted to be a part of the group. We were great, and I loved the group, and I loved being in a great group. However, a couple of things were going on. The first thing is that success had subtly changed Amazin' Blue. When I joined Amazin' Blue, I joined a group of people who were largely midwest hicks, not far removed from my own Upstate hickness. These people WOULD get together on the weekends to watch Star Trek and eat pizza. There was kind of a relaxed atmosphere and so forth. However, after Amazin' Blue was granted the a cappella counterpart to the Midas Touch, suddenly pressure was on. We had to be better than the other campus groups; we had to be better than the other groups with which we performed; we had to be the best a cappella thing on the planet. And, for the most part, we were. (Not always, though. The 1992 Oberlin Obertones: WOW!) This was a lot of stress at a time in my life when I didn't need stress. Although I was able to achieve my B.A. without really giving it much thought, suddenly I didn't know how far I wanted to go in grad school, what field I wanted to go into, and what I wanted to do with my life. In other words, I had more stress than I needed anyway, even without Amazin' Blue. Singing, then, instead of being the stress relief it had always been, became an even greater of source of stress. And yet, I couldn't leave; the group was so darn good! My behavior became erratic, and I started doing things that today I would never believe I was capable of doing, except that I remember behaving that way. Anyway, after much brooding, and after a number of interpersonal conflicts which, in my case, involves more brooding rather than shouting since I am an introverted person, I finally stepped down. Amazin' Blue is still active and still wonderful. A few years ago, they even performed in Carnegie Hall. The current members don't want the same thing from a cappella as my pitchmates and I did back in 1989, but times change, music changes, and this is a perfectly normal and positive development in group evolution. You can visit their webpage here.

Also, I unofficially maintain a chronology of Amazin' Blue, and an exhaustive list of all of its members throughout history.

Desperate Measures

Desperate Measures was my all-time favorite a cappella experience. Of that there is no question. Wonderful people, wonderful music, wonderful experience.

Desperate Measures was formed by former members of The Friars, The Harmonettes, and Amazin' Blue, a cappella groups at The University of Michigan. Many of these members had graduated college by then, and Desperate Measures was always independent of any school. I would call it a recreational a cappella group. Over time, people came and went, and it became increasingly inaccurate to call it a formation of U-M groups.

I joined in 1994, shortly after I left Amazin' Blue. We sang a couple of songs at the wedding of one of the members. Later that year, we started getting together for real and singing some real stuff on a regular basis every week. Most of us had prior a cappella experience, and those who did not had fantastic musical ability, anyway. We were able to do a sophisticated repertoire, and yet still have a lot of fun. For some reason, the stress and competition just were not there. Is it because we were a little older? Is it because we weren't on the college circuit and thus had little reason to be competitive? Who knows? For whatever reason, it was fantastic!

One of the big highlights with Desperate Measures were being invited to perform at the Monsters of A Cappella concert, a show that many of us had back when we were in our U-M groups. We did a fantastic job and made a lot of friends that night. Our other big emotional high was when we had the privilege of performing at the afterglow for Broadway diva Betty Buckley, when she performed in Ann Arbor. We learned a song especially for her: the theme song from Eight is Enough, her hit TV show from the 1970's.

However, in 1998, one by one, we all got involved in other interests. Some of us were going back to school. Some of us were finishing school. Others wanted to perform other kinds of music, so we broke up, absolutely amicably. We did have a couple of reunion concerts afterward; in specific, we sang just before I moved from Ann Arbor to Marquette. What a wonderful group!

2000 ACM Programming Contest

The 2001-2 ACM North Central North American Regional Programming Contest was held simultaneously at numerous sites throughout the region on Saturday 10 November 2000.

In particular, Lake Superior State University, Sault Sainte Marie, MI, hosted teams from several schools:

Algoma University College, Sault Sainte Marie, Ontario, Canada
Lake Superior State University, Sault Sainte Marie, Michigan, USA
Michigan Technological University, Houghton, Michigan, USA
Northern Michigan University, Marquette, Michigan, USA

The contest consisted of 9 problems to be solved over a 5 hour period. No official solutions were published, so what follows are my solutions, written in ANSI C.

Problem 1
Problem 1 Solution
Problem 1 Test Input
Problem 1 Expected Output

Problem 2
Problem 2 Solution
Problem 2 Test Input
Problem 2 Expected Output

Problem 3
Problem 3 Solution
Problem 3 Test Input
Problem 3 Expected Output

Problem 4
Problem 4 Solution
Problem 4 Test Input
Problem 4 Expected Output

Problem 5
Problem 5 Solution
Problem 5 Test Input
Problem 5 Expected Output

Problem 6
Problem 6 Solution
Problem 6 Test Input
Problem 6 Expected Output

Problem 7
Problem 7 Solution
Problem 7 Test Input
Problem 7 Expected Output

Problem 8
Problem 8 Solution
Problem 8 Test Input
Problem 8 Expected Output

Problem 9
Problem 9 Solution
Problem 9 Test Input
Problem 9 Expected Output

For more information, please visit the official contest site.

Problem 9: Number of Numbers

Problem 9: Number of Numbers

Sets of integers having particular properties appear in lots of applications. In this problem, you are to determine the number of integers in a particular set. Each set to be considered has the value first as its smallest value, and the value last as its largest value. first and last are supplied as input data items. Every other integer in the set is larger than first and smaller than last, and also has the property that it differs from another element already in the set by diff (another integer value that will be supplied in the input).

Lets consider an example. Suppose first = 1, last = 10, and diff = 3. Clearly 1 and 10 are in the set. first + diff = 4 is also in the set. last  diff = 7 is in the set as well. Now we can consider 4 + diff = 7 for membership. But 7 is already in the set. Clearly this set includes only the integers 1, 4, 7, and 10. The number of elements in the set is 4, and that would be the proper output for this input.

Input

The input will contain multiple cases. The input for each case contains three integers, specifically first, last, and diff. The input for the last case will be followed by input for which first > last; this case is not to be considered as the specification of another set.

Output

For each input case, display the case number (they are numbered sequentially starting with one), and the number of integers in the set. Leave a blank line between the output for each case. The examples shown below illustrate an acceptable output format.

Sample Input

1 10 3

10 100 10

11 30 19

27 36 4

2 1 0

 

Expected Output

Case 1: Set contains 4 integers.

 

Case 2: Set contains 10 integers.

 

Case 3: Set contains 2 integers.

 

Case 4: Set contains 6 integers.

 

CS 498-02-02F

NORTHERN MICHIGAN UNIVERSITY
CS 498-02
FALL 2002

DIRECTED STUDIES IN COMPUTER SCIENCE: OBJECT ORIENTED DESIGN WITH OBJECTIVE C

3 credits

Time and place to be arranged.

Instructor: Andy Poe, SEAB 1129, 227-1598

Syllabus

Program 1

Program 2

Sample Code

CS 498-02-02F

NORTHERN MICHIGAN UNIVERSITY

CS 498-02

FALL 2002

DIRECTED STUDIES IN COMPUTER SCIENCE:  OBJECT ORIENTED DESIGN WITH OBJECTIVE C

 

 

3 credits

Wednesday 3:00–3:50 P.M. 

Wednesday 28 August 2002 through Wednesday 4 December 2002, except Wednesday 27 November 2002

1129 New Science Facility

 

Instructor: Andy Poe, 1129 New Science Facility, 227-1598

 

This course is an alternative course to CS 326, given for a student who is already proficient in Java and wishes to learn object oriented programming from a different platform.  The course will proceed similarly to CS 326, except that the language used will be Objective C.

 

Office Hours:  My office hours will be from 2:00 P.M.–4:50 P.M. Monday, Wednesday, Thursday, and Friday, except 3:00–4:00 P.M. Wednesday.  Appointments need to be made to see me outside these times.

 

Disability: If you have a need for disability-related accommodations or services, please inform the Coordinator of Disability Services in the Disability Services Office at 1104 University Center (227-1737). Reasonable and effective accommodations and services will be provided to students if requests are made in a timely manner, with appropriate documentation, in accordance with federal, state, and University guidelines.

CS 498-02-02F

CS 498-02-02F

DIRECTED STUDIES IN COMPUTER SCIENCE:  OBJECT ORIENTED DESIGN WITH OBJECTIVE C

FALL 2002

 

Program 1

 

Do Program 1 from this semester's CS 326 class, except do it in Objective C rather than in Java.

 

CS 498-02-02F

CS 498-02-02F

DIRECTED STUDIES IN COMPUTER SCIENCE:  OBJECT ORIENTED DESIGN WITH OBJECTIVE C

FALL 2002

 

Program 2

 

Write a program to sort a linked list in Objective C.

 

The following are Java classes.  Translate them into Objective C.

 

public class LinkedListNode {

 

 public int i;

 public LinkedListNode next;

}

 

public class LinkedList {

 

 public LinkedListNode head;

 public void sort ();

}

 

Now, I made the data fields public.  However, all data fields in a true object-oriented class ought to be private.  So, you will have to make them private and make public get and set methods to use them.  The sort method should sort the linked list nodes into increasing numerical order.  AND, it must do so without changing the data fields; it must manipulate pointers only.

 

For example, if the linked list was originally:

 

head-> 7 -> 3 -> 9 -> 6 -> 2 -> NULL

 

After running sort(), it should look like this:

 

head -> 2 -> 3 -> 6 -> 7 -> 9 -> NULL

 

Hello World NMU INVITATIONAL PROGRAMMING CONTEST #3

The second annual NMU Invitational Programming Contest was held from 12:00 to 5:00 P.M. EST on Saturday 23 March 2002 at Northern Michigan University. The contest was organized by the NMU student chapter of the ACM and was attended by a total of 18 teams from the following 4 schools.

Algoma University College, Sault Sainte Marie, Ontario, Canada
Lake Superior State University, Sault Sainte Marie, Michigan, USA
Michigan Technological University, Houghton, Michigan, USA
Northern Michigan University, Marquette, Michigan, USA

The contest consisted of 6 problems to be solved over a 5 hour period.

Here is the list of rules.

Below is the list of problems, test input files, correct output files, and sample solutions. There were many ways to solve the problems, of course. These solutions were written in ANSI C, and should compile on any C/C++ compiler.

Problem 1
Problem 1 Input File
Problem 1 Output File
Problem 1 Solution

Problem 2
Problem 2 Input File
Problem 2 Output File
Problem 2 Solution

Problem 3
Problem 3 Input File
Problem 3 Output File
Problem 3 Solution

Problem 4
Problem 4 Input File
Problem 4 Output File
Problem 4 Solution

Problem 5
Problem 5 Input File
Problem 5 Output File
Problem 5 Solution

Problem 6
Problem 6 Input File
Problem 6 Output File
Problem 6 Solution

MTU BLUE won the competition.
Second place went to MTU RED.
Third place went to ALGOMA B.

The winning school was Michigan Technological University.

Here are the complete results. OFFICIAL RULES

NMU PROGRAMMING CONTEST #3

Saturday 23 March 2002

 

1.  A team consists of at most three members.  Each team will have a single computer at its disposal to develop solutions to the assigned problems.  The team may share use of the computer in any way it sees fit to do so.  The team may solve the problems individually or collectively at its discretion.  However, a team member may not communicate—personally, electronically, or otherwise—with anyone other than a judge (via runner) or another member of the same team during the contest.

 

2.  The judges will be happy to answer questions of clarification during the contest and are willing to assist with technical difficulties, but they cannot provide any hints or information relating to how the problems should be solved.

 

3.  There are 6 problem specifications and 5 hours in which to solve them.  The problems need not be of equivalent difficulty with each other and are given in no particular order.  They may be solved in whatever order the team sees fit.  The team may solve the problems with any compiled language or with Java.  The team is not constrained to using the same language for each problem; each problem is solved completely independently of the others.  If a problem is solved with a compiled language, the team is to generate a single file called prob*.exe , where * (defined here and used hereafter) is the digit between 1 and 6 corresponding to the problem being solved.  This file should be either a Windows or DOS executable file compatible with Windows ME, the system on which the problems will be judged.  If a problem is solved with Java, the team is to generate one or more files ending with .class , corresponding to the classes used to solve the problem.  The main class must be called prob*.class .  The class files must be compatible with Java 2 SDK v. 1.3.1, the Java interpreter being used to test these solutions.  Compilers for C, C++, and Java will be provided.  It should be understood, though, that the problems were defined with C in mind, and that the official solutions will be in C.  The team may use any printed reference materials during the contest but is disallowed from using the Internet and from using media (such as magnetic or optical) specifically designed for computer reading.

 

4.  The executed program will open an existing file, prob*.in , for reading, and will create and open a file, prob*.out, for writing.  The program must use these files and no others.  The use of other files will cause the program to fail during judicial testing.  Any output sent to the screen will be ignored by the judges; only the output sent to prob*.out will be evaluated.  The judge will not enter information to the program via the keyboard, so any attempt to read from the keyboard will cause the program to hang during judicial testing, thus disqualifying it (see below).  If Java is used to solve a problem, it must be run as an application, rather than an applet; applets cannot modify files.  Any graphical output will be ignored; any request for GUI input will be ignored, thus disqualifying the program, as above.

 

5.  prob*.in and prob*.out are text files.  They will be constrained to containing only the 94 visible ASCII characters, the space character (no program will be required to parse or print a <TAB> character) and the end-of-line character, which varies between systems and will be denoted by <EOLN>.  In the Windows/DOS environment, <EOLN> is actually represented by two consecutive ASCII characters:  13,10.  Most programming languages developed for the Windows environment handle this two-byte representation naturally, with no extra effort required on the part of the programmer; in particular, the “\n” representation for the end-of-line character in C/C++ in Windows does indeed refer to the required two-byte sequence.  All files are terminated with the end-of-file marker, denoted by <EOF>, which also varies between systems.  In the Windows/DOS environment, <EOF> is handled automatically by the operating system, and no special care need be taken to ensure that it is written properly.  The team may assume that the judicial input file will be formatted correctly—it is not necessary to check for syntax errors.  The output file must be formatted exactly to specification.  For each valid input file, there will be one and only one correct output file.  A program that yields an incorrectly formatted output file will be judged to be incorrect, even if the bulk of the program performs correctly.  Each problem specification will contain a sample input and output file, but this sample need not be the same input file used for judicial testing.

 

6.  Just prior to the beginning of the competition, each team will send one representative to a designated location to receive their packet.  All teams will be given their packets simultaneously, and the 5-hour countdown will begin at that second.  Within this packet will be three copies of the problem specifications and six floppy diskettes.  Each diskette will be designated for one specific problem.  Each diskette will contain a hidden identification file, which must not be removed or modified in any way.  When a solution has been developed for a particular problem, the team will place either prob*.exe or a collection of .class files on the appropriate diskette and will deliver that diskette to a judge (via runner), who will mark the time of receipt.  No other files should be placed on this diskette; in particular, the source code itself should not appear on the diskette.  The judge will execute the submitted program against a preexisting prob*.in file.  The generated prob*.out file will be compared against the one and only correct output file.  The team will be told (via runner) whether it has successfully generated the correct output file, but in the event that the output file is incorrect, no information beyond the fact that it is incorrect will be revealed to the team.  Any run-time error in the program will cause the solution to be judged incorrect, even if the correct output file is generated despite this.  The sample solutions all run “instantly” on the official input file; any submitted program that takes longer than 5 seconds to execute will be considered an incorrect solution, but, again, the only information revealed to the team will be that the solution was incorrect.  The official input files will not be revealed to the teams or to any member thereof until after the competition has terminated.  If a submission is judged to be incorrect, the diskette will be returned to the team; the team will be allowed to submit as many solutions as they like to a problem (with a penalty, see below).  If a submission is judged to be correct, the diskette will be retained by the judges.  All diskettes are to be returned to the judges at the termination of the competition.

 

7.  All communication between the judges and contestants will occur via intermediaries, known as runners.  Any question or request must be made in writing and handed to a runner who will deliver the message to a judge.  The judge's response will also be in writing.  At no time during the competition are the judges and contestants to communicate face-to-face.  The runners may also be used to obtain paper copies of programs in progress.  Just give a runner a diskette with a file you would like printed.

 

8.  All attempted solutions will be archived by the judges.  There will be no known error in the problems by any of the judges prior to the competition, but if an error is discovered in either the problems or the judging during the course of the competition or during the course of a challenge afterward, the archived solutions will be reexamined and the scores retabulated based on these results.  Aside from this retabulation, no further remedy will be offered.  (In particular, if a team uses a large part of its resources to ferret out a non-existent bug in an improperly rejected solution, it will not be offered compensatory time.)  However, as stated, care will be taken to prevent errors from occurring before the competition begins, so that, hopefully, this situation will not arise.

 

9.  Any attempt by the executed program to copy or damage the preexisting input file in any fashion or to demean the integrity of the contest in any way will result in the immediate disqualification of the submitting team.

 

10.  Scoring is determined by a pair of integers as follows:  The count for each term is the number of problems solved.  The total for each team is the total number of minutes required to solve each problem starting from the beginning of the contest.  A penalty of 20 minutes is added to the total for each unsuccessful attempted solution of a problem, provided that a correct solution of that problem is eventually submitted.  More precisely:  at the beginning of the competition, count and total are initialized to zero.  Upon the evaluation of a correct submission, count is incremented by one, total is incremented by the number of minutes between the start of the contest and the submission of the executable, and total is further incremented by 20 for each incorrect solution to the problem submitted prior to the correct one.

 

11.  Team ranking is determined by each team's count, with the highest count being ranked first.  Ties are broken by total, in favor of the team with the lowest total.  Any subsequent ties remain unbroken.  With this in mind, it is to the team's advantage to seek out and complete the easier problems first.  This will result in a smaller total.  However, keep in mind as well that difficulty is a matter of individual perception, and that the problems are given in no particular order.

 

12.  Schools may submit as many teams as they care to.  School ranking is determined by summing the count values and summing the total values of the three highest-ranking teams affiliated with that school.  These aggregate values are used as above to rank the participating schools.  Schools that submit fewer than three teams are thus disadvantaged in the school ranking; however, schools that submit more than three teams have no gross advantage, in that most schools can predict which of their teams will be the three highest-ranking.  Note that ties only occur if both count and total are identical, so if there is more than one team in third place, it does not matter which is added to the aggregate score.

 

13.  Schools are not constrained to submitting a number of contestants that is divisible by three.  Teams must not contain more than three members, but may contain fewer.  Additionally, individuals unaffiliated with a team may attend as well and may form teams with other unaffiliated individuals from their own or other schools or from no school.  Such hybrid teams are entitled to their team ranking and to any formal acknowledgement thereof, but their scores cannot be figured into the aggregate score for any school under any circumstances.

 

REMINDERS

 

1.  When a program fails, the team will be only be told that it failed; no specific reason will be given.  You may have made a simple careless error such as those described below.

 

2.  Failure to format the output file exactly as specified will cause the program to fail.

 

3.  Failure to name the submission, input, and output files exactly as specified will cause the program to fail.

 

4.  Failure to submit the program on the correct diskette will cause the program to fail.

 

5.  Reading input from the keyboard or specifying input from a Graphical User Interface will cause the program to fail.

 

6.  Screen and graphical output will be absolutely ignored.

 

7.  You will be penalized for programs that fail.

 

8.  <EOLN> and <EOF> in the specifications refer to the end-of-line and end-of-file markers.  They do not represent the literal strings "<EOLN>" and "<EOF>".  Similarly, each space in the sample input and output files will be represented by ·.

 

 

INSPIRATION AND DIFFERENCES

 

This competition is modeled on the ACM International Programming Contest.  Here are some ways in which this competition differs from the one sponsored by the ACM.

 

1.  The winner(s) of this competition do not compete in a higher competition following this one.  This buck stops here.

 

2.  In this contest, according to the official rules, no reason will be given whatsoever for a program failure, as the ACM has several (overlapping and confusing, in my opinion) categories in which errors can lie.  However, in the past, the contest judge (who is also the author of these rules) hasn't had the heart to be brutally binary in all judgments.  The judge reserves the right to give nonspecific information pertaining to a failure as long as it is done in a fair and impartial manner.

 

3.  Any compiled language (as well as Java) is acceptable in this competition.  The ACM restricts its competition to certain languages.

 

4.  All problems in this competition are specified completely without ambiguity.  There is one and only one correct output file for every valid input file.  The ACM competition allows for a certain amount of ambiguity.

 

5.  There is no designation in this competition between official and unofficial teams.  All teams are welcome to participate.  The only caveat is that hybrid teams from multiple schools or containing non-students as members may not contribute to any aggregate school score.

 

6.  All registered students are eligible to compete for the school they attend.  The ACM competition limits the participation of graduate students.

 

REDIRECTING INPUT AND OUTPUT

 

Many participants in these competitions wonder how to read program input from a file and how to write program output to a file, rather than using standard input and output.  Here is how to do it in some languages; if you're using a different language, you'll have to look it up on your own.

 

C:

 

FILE *in, *out;

.

.

.

in = fopen ("prob1.in","r");

out = fopen ("prob1.out","w");

.

.

.

fscanf (in,...);

fprintf (out,...);

 

C++:

 

ifstream in ("prob1.in");

ofstrean out ("prob1.out");

.

.

.

in >> ...;

out << ...;

 

Java:

 

BufferedReader in = new BufferedReader (new FileReader ("prob1.in"));

PrintStream out = new PrintStream (new FileOutputStream ("prob1.out"));

.

.

.

... = in.readLine();

out.println (...);

 

Pascal:

 

VAR

 IN, OUT : TEXT;

 

.

.

.

RESET (IN,"prob1.in");

REWRITE (OUT,"prob1.out");

.

.

.

READLN (IN,...);

WRITELN (OUT,...);

 

Sample Questions

 

My Web Page always has old problems and solutions from this and from other similar competitions.  Check it out:  http://euclid.nmu.edu/~apoe

 

Using TextPad

 

TextPad is the world's easiest editor/compiler.  Just follow these simple guidelines and you should have no trouble submitting programs in the contest.

 

1.  Every file you make is a text file.  There are no “Project” files or any other nasty bloated thing you have to worry about.

 

2.  Use the File menu to create new documents, to open existing documents or to save documents.  Java files should end in .java .  You can save C/C++ files with .c, .cpp, or .cc .

 

3.  Use the Tools menu to compile and run Java and C/C++.  If you are using Java, be sure that you Run Java Application.  Applets are not acceptable for this contest.

 

4.  When you hand in a solution, put the executable (.exe file) on your floppy.  Nothing else.  Don't waste my time with the source code.  If you are using Java, put EVERY .class file on your disk.  Even if you put multiple classes in the same source file, the Java compiler will make a separate .class file for each one.

 

5.  That's it!!!!

 

Problem1--Changing Mazes

Problem 1—Changing Maze

 

Luke Skywalker and his sister/love interest Leia are trying to get through a killer maze.  And I mean killer!  Every time step, the boundaries change.  If our twins/lovebirds ever visit a square the same time a boundary appears, they're toast.  There is no need to panic; the Force will guide them through the maze, and they will not die.  However, the Force needs to know what advice to give and is therefore asking you for help.

 

Luke and Laura begin in the northwest corner of a maze.  They want to make it to the southeast corner of the maze.  At any given time step, Luke and Laura can move one square north, south, east, or west, or they can stay where they are.  At every time step, the boundaries of the maze change:  there is a finite list of patterns; if Luke and Laura are still in the maze when the list of patterns is exhausted, the maze cycles through again from the beginning of the list.  You need to compute whether Luke and Laura can make it to the southeast corner of the maze, and, if so, the minimum number of time steps necessary for them to get there.  Remember, the Force is counting on you!  If you give the Force bad advice, we'll have to wait around for A Newer Hope and Force Knows how long that could take!

 

INPUT SPECIFICATION. The input file will consist of several case.  Each case (but the last) will begin with a line containing three decimal integers.  The first is the number of rows in the maze; the second is the number of columns in the maze; the third is the number of patterns in the list.  The first two numbers will be inclusively between 1 and 20; the third will be inclusively between 1 and 10.  The integers will be separated by exactly one space and will be followed by exactly one <EOLN>.  Immediately following this line will be a number of patterns, equal to the number specified on the first line.  Each pattern will consist of r lines each containing c characters, where r is the number of rows and c is the number of columns indicated on the first line.  Each character will be either 0 (indicating no boundary) or 1 (indicating a boundary).  Each line will be terminated by <EOLN>, and an extra <EOLN> will follow each pattern.  The northwest corner of the first pattern will always be zero, since Luke and Laura will be starting from there.  The last case will be three zeros, separated by exactly one space and followed by exactly one <EOLN>.  This case is not to be processed; it indicates the end of input.

 

OUTPUT SPECIFICATION.  The output cases are to appear in the same order in which they appear in the input file.  Each output case should be of the form “Case c:  Luke and Leia can escape in s steps.” or of the form “Case c:  Luke and Leia cannot escape.” c and s are decimal integers.  c is the number of the case being processed (starting with 1) and s is the minimum number of time steps Luke and Leia require to reach the southeast corner.  Each line should be terminated by exactly one <EOLN>.  Remember:  format counts.  Be sure your output is formatted exactly as demonstrated below.

 

SAMPLE INPUT.

 

5·5·1<EOLN>

00000<EOLN>

00000<EOLN>

00000<EOLN>

00000<EOLN>

00000<EOLN>

<EOLN>

5·5·2<EOLN>

00000<EOLN>

00000<EOLN>

00000<EOLN>

00000<EOLN>

00000<EOLN>

<EOLN>

01110<EOLN>

01110<EOLN>

11111<EOLN>

01110<EOLN>

01110<EOLN>

<EOLN>

0·0·0<EOLN>

<EOF>

 

SAMPLE OUTPUT.

 

Case·1:··Luke·and·Leia·can·escape·in·8·steps.<EOLN>

Case·2:··Luka·and·Leia·cannot·escape.<EOLN>

<EOF>

Problem 2--Packing Bricks

Problem 2—Packing Bricks

 

Boss Nass wants to build a new palace and has assigned Jar Jar Binks the task of packing bricks into boxes for shipping.  Well, packing bricks is a mind-numbing task for someone of Jar Jar's advanced intellect, so he finds himself pondering great philosophical questions:  Is there a Force, is a dictatorship a more efficient form of government than a republic, and what is the maximum number of bricks I can put into a single box?

 

The first two questions are, of course, highly subjective, but you can help Jar Jar with the last.  Given the dimensions of the box, and the dimensions of the bricks, you are to compute the maximum number of bricks Jar Jar can put in the box.  Here are some restrictions:  the box and all bricks are rectangular solids; all the bricks are identical; Jar Jar isn't so clever about weird geometric packings, so all bricks will be laid in with their edges parallel to the edges of the box (no diagonal placings or anything) and all bricks will be oriented identically in the box (no criss-crossings).

 

INPUT SPECIFICATION. The input file will consist of several lines.  Each line (but the last) will contain 6 positive decimal integers no larger than 10000.  The first three represent the dimensions of the box.  The last three represent the dimensions of the bricks.  There will be one or more spaces separating adjacent integers on the line, and the line will be terminated by exactly one <EOLN>.  The last line will contain three zeros, separated by one or more spaces, followed by <EOLN>.  This line is not to be processed; it merely signifies the end of the input.

 

OUTPUT SPECIFICATION.  The output cases are to appear in the same order in which they appear in the input file.  For each case, you are to print “Case c:  Jar Jar can fit b bricks in the box.”  c and b are decimal integers:  c is the number of the case being processed, beginning with 1; b is the number of bricks Jar Jar can pack in that case.  The statement should be followed by two <EOLN>'s, which is to say that a blank line should follow every output case.  Remember:  format counts.  Be sure your output is formatted exactly as demonstrated below.

 

SAMPLE INPUT.

 

24·12·90·····8·6·30<EOLN>

100·100·100··2·2·200<EOLN>

0·0·0<EOLN>

<EOF>

 

SAMPLE OUTPUT.

 

Case·1:··Jar·Jar·can·fit·18·bricks·in·the·box.<EOLN>

<EOLN>

Case·2:··Jar·Jar·can·fit·0·bricks·in·the·box.<EOLN>

<EOLN>

<EOF>

 

Problem 3--Christmas Trees

Problem 3—Christmas Trees

 

Christmas is always fun at the rebel home base.  This year they are buying two Christmas trees and are placing them in elevated stands so that the tops of the trees are level even if the trees are of different heights.  Given the heights of the trees, you are to print a picture of the two Christmas trees.

 

INPUT SPECIFICATION. The input file will consist of several lines.  Each line (but the last) will contain two positive decimal integers no larger than 100.  These integers will be separated by exactly one space and will be followed by exactly one <EOLN>.  These integers represent the sizes of the trees; the size of the left tree is followed by the size of the right tree.  The last line will contain two zeros, separated by one space and terminated by one <EOLN>.  This line is not to be processed; it merely signifies the end of the input.

 

OUTPUT SPECIFICATION.  The output cases are to appear in the same order in which they appear in the input file.  A full specification is not necessary; the examples will suffice, but here are a few pointers:  The height of the stem is the same as the input integer; the height of the branches is twice that.  The tops of the trees are level; the bottoms need not be.  There is exactly one space between trees, which is to say, between the trees is there is exactly one vertical column consisting only of spaces.  All trailing spaces are trimmed from each line before printing; the last character of any line in the output file should not be a space.  There should be exactly one blank line following each output case.

 

SAMPLE INPUT.

 

2·3<EOLN>

3·2<EOLN>

0·0<EOLN>

<EOF>

 

SAMPLE OUTPUT.

 

···*·········*<EOLN>

··***·······***<EOLN>

·*****·····*****<EOLN>

*******···*******<EOLN>

···*·····*********<EOLN>

···*····***********<EOLN>

·············*<EOLN>

·············*<EOLN>

·············*<EOLN>

<EOLN>

·····*·········*<EOLN>

····***·······***<EOLN>

···*****·····*****<EOLN>

··*******···*******<EOLN>

·*********·····*<EOLN>

***********····*<EOLN>

·····*<EOLN>

·····*<EOLN>

·····*<EOLN>

<EOLN>

<EOF>

Problem 4--Double Near Palindromes

Problem 4—Double Near Palindromes

 

C-3PO is an expert in pretty much every language.  His conversations with R2-D2 are always fun to observe in that R2-D2 speaks in Droid, C-3PO speaks in English, and they understand each other perfectly!  Anyway, humans and droids both enjoy playing word games.  A palindrome is a word or sequence of one or more letters that reads the same forwards and backwards.  A near palindrome is a word or sequence that can be changed to or kept a palindrome by changing exactly one letter to a different letter.  For example, BAT is a near palindrome, since changing the T to a B would make the word a palindrome: BAB.  PEEP is not a near palindrome; although PEEP is palindrome, changing any letter would remove its palindrome status.  A double near palindrome is a word or sequence that consists of two near palindromes concatenated together.  For example, BATMAN is a double near palindrome, since BAT and MAN are both near palindromes.  Given a list of words, you are to determine which words are double near palindromes and which are not.

 

INPUT SPECIFICATION.  The input file will consist of one or more words.  All words (except the last) will be inclusively between 1 and 25 letters long and will consist of entirely of capital letters.  The last word will be “*END*” and is not to be processed; it simply indicates the end of the input.  There may be any number of spaces and <EOLN> characters before, after, and between words.

 

OUTPUT SPECIFICATION.  The output cases are to appear in the same order in which they appear in the input file.  For each input case, you are to print either “w is a double near palindrome.” or “w is not a double near palindrome.” whichever is appropriate, where w is the input word.  Exactly one <EOLN> should follow each output case (meaning there should be no blank lines in the output file).

 

SAMPLE INPUT.

 

BATMAN<EOLN>

CONSTANTINOPLE<EOLN>

*END*<EOLN>

<EOF>

 

SAMPLE·OUTPUT.

 

BATMAN·is·a·double·near·palindrome.<EOLN>

CONSTANTINOPLE·is·not·a·double·near·palindrome.<EOLN>

<EOF>

Problem 5--The Knights of the Round Circle

Problem 5—The Knights of the Round Circle

 

A group of Jedi Knights is having a competition.  One of the Knights at random stands within a circle.  The other Knights, in a random order, challenge him.  If a challenger defeats the Knight of the Round Circle, that Knight must leave the contest.  The challenger then becomes the new Knight of the Round Circle and, as such, will face all subsequent challengers until he is defeated.  If the current Knight of the Round Circle wins the challenge, he stays within the circle and the challenger must leave the competition.  The Knight within the circle at the end of the competition is deemed the winner.  You may assume that no two Knights have exactly the same skill and that a stronger Knight will always defeat a weaker Knight.

 

Suppose there are three Knights in the competition.  If the strongest one happens to stand in the circle first, he will not be defeated, so no one will ever leave the circle.  If the weakest one happens to be first in the circle, he will be kicked out after his first match.  If the Knight that defeated him was the strongest, he will win the final challenge as well (so only one Knight will ever leave the circle), otherwise the strongest Knight will kick the middle Knight out of the circle during his challenge (so that two Knights leave the circle).  If the middle Knight stands in the circle first, he will be the only one kicked out of the circle, no matter what order the other two come at him.  All in all, an average of 5/6 or 0.83 Knights will leave the circle during the competition.

 

You are to compute the average number of Knights to leave the circle during a competition given the number of Knights in the competition.

 

INPUT SPECIFICATION. The input file will consist of several lines.  Each line (but the last) will contain one positive decimal integer no larger than 10000.  This integer will be followed by exactly one <EOLN>.  These integers represent the number of Knights in the competition.  The last line will contain one zero, followed by <EOLN>.  This line is not to be processed; it merely signifies the end of the input.

 

OUTPUT SPECIFICATION.  The output cases are to appear in the same order in which they appear in the input file.  For each case, you are to print “With c competitors, a Jedi Knight will be replaced approximately t times.”  c is the number of competitors in this case and should be a decimal integer.  t is the average number of times a Jedi Knight leaves the circle and should be a floating point decimal number with exactly two digits following the decimal point.  There should always be at least one digit before the decimal point (use 0.50 rather .50, for example.)  The statement should be followed by two <EOLN>'s, which is to say that a blank line should follow every output case.

 

SAMPLE INPUT.

 

3<EOLN>

1000<EOLN>

0<EOLN>

<EOF>

 

SAMPLE OUTPUT.

 

With·3·competitors,·a·Jedi·Knight·will·be·replaced·approximately·0.83·times.<EOLN>

<EOLN>

With·1000·competitors,·a·Jedi·Knight·will·be·replaced·approximately·6.49·times.<EOLN>

<EOLN>

<EOF>

 

Problem 6--Great Circles

Problem 6—Great Circles

 

It is a remarkable coincidence that every planet in the Republic is a perfect sphere.  Furthermore, every culture developed the terms “North Pole,” “South Pole,” “Equator,” and “Prime Meridian” just as humans did.  Every culture also measures angles in degrees and distances in kilometers (“parsecs,” of course, being a measure of time).  Also, although the planets are of different sizes, every culture has a latitude and longitude system just as Earth does:  latitude is measured in degrees north and south of the equator, up to 90; longitude is measured in degrees east and west of the prime meridian, up to 180. 

 

Every culture has an airline system, and these airlines want to fly the shortest possible route connecting points on their planet.  It turns out that the shortest route between points on a sphere is called the Great Circle Route.  A great circle is a circle on the sphere whose center is also the center of the sphere.  The shortest distance between two points on a sphere is along a great circle containing both of those points.  Computing this distance isn't too difficult either.  Here's one way:  first you draw a triangle (with straight lines) whose vertices are the two given points and the center of the planet.  You then find the lengths of these sides:  two of the sides have length equal to the radius of the planet, and the length of the third side is the direct (underground) distance between the two given points.  Since you have all sides of the triangle, you can then compute the angle at the center of the planet, and with this piece of information and the radius of the planet, you can then compute the length of the arc of the great circle that connects these two points.

 

Using this or another method, compute great circle distances for various points on various planets in the Republic.

 

INPUT SPECIFICATION. The input file will consist of several lines.  Each line (but the last) will contain a decimal integer inclusively between 1000 and 100000 indicating the circumference of the planet (in km), one space, one planetary point, one space, a second planetary point, <EOLN>.  A planetary point consists of this information:  a decimal integer inclusively between 0 and 90 indicating the latitude, one space, “N” or “S” indicating the direction of latitude, one space, a decimal integer inclusively between 0 and 180 indicating the longitude, one space, “E” or “W” indicating the direction of longitude.  The last line will simply be 100<EOLN>, and indicates the end of input.

 

OUTPUT SPECIFICATION.  The output cases are to appear in the same order in which they appear in the input file.  Each output case should be of the form:  “Case c:  Cities are d km apart.”  c and d are decimal integers; c is the number of the case being processed (starting with 1) and d is the distance in km between the two points, rounded to the nearest integer.  Each line should be terminated by exactly one <EOLN>.  Remember:  format counts.  Be sure your output is formatted exactly as demonstrated below.

 

SAMPLE INPUT.

 

40000·90·N·23·E·90·S·38·W<EOLN>

25000·46·N·87·W·40·N·90·W<EOLN>

100<EOLN>

<EOF>

 

SAMPLE OUTPUT.

 

Case·1:··Cities·are·20000·km·apart.<EOLN>

Case·2:··Cities·are·444·km·apart.<EOLN>

<EOF>

CS 126-01-02F

NORTHERN MICHIGAN UNIVERSITY
CS 126-01
FALL 2002

COMPUTER SCIENCE COLLOQIUM

1 credit

Thursday 11:00 - 11:50 A.M.

NSF 1205

Instructor: Andy Poe, NSF 1129, 227-1598

Syllabus

CS 126-01-02F

NORTHERN MICHIGAN UNIVERSITY

CS 126-01

FALL 2002

COMPUTER SCIENCE COLLOQUIUM

 

 

4 credits

Thursday 11:00–11:50 A.M. 

Thursday 29 August 2002 through Thursday 5 December 2002, except Thursday 28 November 2002

No Final Exam

1205 New Science Facility

Instructor: Andy Poe, 1129 New Science Facility, 227-1598

 

This course is REQUIRED for all “older” Computer Science and Network Computing majors.  This course is not required for all “newer” majors.  The course consists entirely of attending presentations and writing briefs.

 

Text:  No text.

 

Courseload:  Approximately once every two weeks, a speaker will discuss some general area of Computer Science.  You are to write a one- or two-page paper on this talk.  All papers will be graded S/U, and the course itself will be graded S/U.

 

Office Hours:  My office hours will be from 2:00 P.M.–4:50 P.M. Monday, Wednesday, Thursday, and Friday, except 3:00 P.M.–4:00 P.M. Wednesday.  Appointments need to be made to see me outside these times.

 

Disability: If you have a need for disability-related accommodations or services, please inform the Coordinator of Disability Services in the Disability Services Office at 1104 University Center (227-1737). Reasonable and effective accommodations and services will be provided to students if requests are made in a timely manner, with appropriate documentation, in accordance with federal, state, and University guidelines.

CS 228-01-02F

NORTHERN MICHIGAN UNIVERSITY
CS 228-01
FALL 2002

NETWORK PROGRAMMING

4 credits

Monday Wednesday Thursday Friday 10:00 - 10:50 A.M.

WEST 3805

Instructor: Andy Poe, NSF 1129, 227-1598

Syllabus

Program 1
Executable

Program 2
Parent Executable from part 1
Child Executable from part 1
Executable from part 2

Program 3

Basic Linux Commands
Sample Code

CS 228-01-02F

NORTHERN MICHIGAN UNIVERSITY

CS 228-01

FALL 2002

NETWORK PROGRAMMING

 

 

4 credits

Monday Wednesday Thursday Friday 10:00–10:50 A.M. 

Monday 26 August 2002 through Friday 6 December 2002, except Monday 2 September 2002, Friday 11 October 2002, Friday 1 November 2002, and Wednesday 27 November 2002 through Friday 29 November 2002

Final Exam:  Monday 9 December 2002 10:00–11:50 A.M.

3805 West Science

Instructor: Andy Poe, 1129 New Science Facility, 227-1598

 

This course is REQUIRED for all Computer Science and Network Computing majors.

 

Text:  Computer Networks, Third Edition, Andrew S. Tanenbaum.  This book is available from the University Center Bookstore, but there is no law that says you must get the book from there.  You might want to consider checking prices at amazon.com or bookpool.com .

 

Courseload:  There will be weekly assignments, some programming, some written.  These will be worth 60% of your grade.  There will be two in-class exams, worth 10% each, and a final exam worth 20%.

 

Office Hours:  My office hours will be from 2:00 P.M.–4:50 P.M. Monday, Wednesday, Thursday, and Friday, except 3:00 P.M.–4:00 P.M. Wednesday.  Appointments need to be made to see me outside these times.

 

Disability: If you have a need for disability-related accommodations or services, please inform the Coordinator of Disability Services in the Disability Services Office at 1104 University Center (227-1737). Reasonable and effective accommodations and services will be provided to students if requests are made in a timely manner, with appropriate documentation, in accordance with federal, state, and University guidelines.

CS 228-01-02F

CS 228-01-02F

NETWORK PROGRAMMING

FALL 2002

 

Program 1

Due:  Friday 6 September 2002  10:00 A.M. EDT

 

 

Write a program in C++ that does the following:

 

1.  It asks the user to enter the name of a file.  You may assume that the file so named does exist and that there is nothing funny going on with it.

 

2.  It opens the file so named and reads in words until the file is exhausted.  Each word consists only of letters and may be separated by any amount of white space (spaces, tabs, return characters).

 

3.  For each word, your program should print out whether the word is a palindrome.  A palindrome is the word that reads the same backwards as forwards.  For example, “racecar” is a palindrome but “racecars” is not.

 

4.  Your program should be case-insensitive.  That means that it should not distinguish between upper- and lowercase letters.  “RacecAr” is a perfectly fine palindrome.

 

5.  You should divide your program into appropriate methods and you should comment it well!

 

Palindromes are interesting things; most people think of palindromes as sentences, such as “A man, a plan, a canal:  Panama.”  Such a sentence reads the same forward and backward if it is interpreted case-insensitive and if spaces and punctuation don't count.  Your program shouldn't check for sentences, though; it should only check individual words.  A palindrome is considered good if the sentence actually expresses something interesting; the one above is a classic.  Another famous palindrome that actually won a contest once is “Doc, note, I dissent; a fast never prevents a fatness.  I diet on cod.”

 

There was a contest once where you had to write a palindrome around U.S. Presidents.  One of the entries was “No ‘x’ in Mr. R. M. Nixon?” which doesn't make any sense.  The winner was “Taft:  fat!”

 

 

CS 228-01-02F

Introductory Linux Stuff

 

CONNECTING to turing.

 

Run putty, tell it to connect to turing.nmu.edu with the SSH box checked.  Enter your username and password.

 

Start up a vnc shell by typing vncserver.  It will give you a number; remember it.  Start the vncviewer on the laptop.  Enter turing.nmu.edu:## where ## is the number that vncserver gave you a few minutes ago.  Enter your password.

 

DISCONNECTING from turing.

 

Close all the Linux windows in your vnc window.  Close the vnc window.  In your putty window, type vncserver -kill :## where ## is the number above.  Exit putty (the exit command should work).

 

Some useful Linux commands:

 

cd dirname

Changes directory to the one specified.  cd .. will move you to the directory containing yours.

 

mkdir dirname

Makes a new directory.

 

cp oldfile newfile

Makes a copy of oldfile called newfile.

 

cp oldfile dirname

Puts a copy of oldfile into dirname.

 

mv oldfile newfile

Changes the name of oldfile to newfile.

 

mv oldfile dirname

Moves oldfile to dirname.  The original oldfile vanishes.

 

rm filename

Deletes a file.

 

rmdir dirname

Deletes a directory.  Will not delete a directory with stuff inside it.

 

rm -rf dirname

Completely obliterates a directory and all its stuff.

 

man command

Gives information on command.

 

g++ prog.cc -O3 -Wall -o prog

Compiles C++ program prog.

 

xterm -e pico file &

Throws up a pico window to edit a file.

CS 228-01-02F

CS 228-01-02F

NETWORK PROGRAMMING

FALL 2002

 

Program 2

Due:  Friday 13 September 2002  10:00 A.M. EDT

 

 

1.  Write a program in C++ that accepts an integer on the command line.  The program should divide the integer by 37 and return the remainder.  It should not read or write anything.

 

Write a second program in C++ that asks the user for an integer.  It should read in the integer and then execute the first program on that integer.  That first program should then return the remainder of that number divided by 37.  The second program should then print out that value.

 

Note:  The second program does all the input and output.  The first program does all the computation.

 

 

 

 

 

 

2.  Write a program in C++ that opens a pipe and forks a copy of itself.  The parent should then ask the user for a string.  The user should type in a string and send that string down the pipe to the child.  The child should reverse the string and send it back to the parent.  The parent should print it out.  In other words, the parent does all the reading and writing.  The child does all of the work.

 

 

Neither of these programs should use the "system" command.  Use low-level calls only.

 

 

CS 228-01-02F

CS 228-01-02F

NETWORK PROGRAMMING

FALL 2002

 

Program 3

Due:  Friday 27 September 2002  10:00 A.M. EDT

 

 

You are to write a server program.  The server will accept one client only.  When the server receives an ls command from the client, the server should send a file listing back to the client.  (It should be fully descriptive:  an “ls -al” command.)  When the server receives a ps command from the client, it should send a process listing back to the client.  (A fully descriptive ps command:  “ps gaxu”.)

 

You are to write a client program.  This client program should get a host address and port number from the command line (e.g.  ./client 198 110 193 20 12345).  The client should connect to the port where the server (described above) is running.  The client should then prompt the user for a command.  If the command is “ls” the client should send that to the server, receive a full file listing and print it out.  If the command is “ps” the client should send that to the server, receive a full process listing and print it out.  If the command is “exit,” the client should halt.  The server should halt at that point, too.  If the command is anything else, the client should print an appropriate error.  The client should keep receiving commands until “exit” is received.

 

At no time should any of the ls or ps information be written to a real file.  In fact, no real file should ever be opened at any time by either program.  All communication must be virtual.

 

Note that the client and server need not be running on identical machines!  You have just written a program to obtain a remote file or remote process listing!

 

CS 498-03-02F

NORTHERN MICHIGAN UNIVERSITY
CS 498-03
FALL 2002

DIRECTED STUDIES IN COMPUTER SCIENCE: VIDEO GAME DESIGN

4 credits

Time and place to be arranged.

Instructor: Andy Poe, SEAB 1129, 227-1598

Syllabus

Program 1

Program 2

Two-dimensional Rotational Formulae

Sample Code

CS 498-03-02F

NORTHERN MICHIGAN UNIVERSITY

CS 498-03

FALL 2002

DIRECTED STUDIES IN COMPUTER SCIENCE:  VIDEO GAME DESIGN

 

 

4 credits

Wednesday 12:00–12:50 P.M. 

Wednesday 28 August 2002 through Wednesday 4 December 2002, except Wednesday 27 November 2002

1129 New Science Facility

Instructor: Andy Poe, 1129 New Science Facility, 227-1598

 

This course is an elective (hopefully becoming a full-fledged course one day) using Allegro to design interactive video games.  Topics will include (but are not limited to) animation, perspective, shading, and sound effects.

 

Office Hours:  My office hours will be from 2:00 P.M.–4:50 P.M. Monday, Wednesday, Thursday, and Friday.  Appointments need to be made to see me outside these times.

 

Disability: If you have a need for disability-related accommodations or services, please inform the Coordinator of Disability Services in the Disability Services Office at 1104 University Center (227-1737). Reasonable and effective accommodations and services will be provided to students if requests are made in a timely manner, with appropriate documentation, in accordance with federal, state, and University guidelines.

CS 498-03-02F

CS 498-03-02F

DIRECTED STUDIES IN COMPUTER SCIENCE:  VIDEO GAME DESIGN

FALL 2002

 

Program 1

 

Use the Allegro software to generate some non-trivial graphics display.  Something involving motion and/or some user interaction would be ideal.

 

CS 498-03-02F

CS 498-03-02F

DIRECTED STUDIES IN COMPUTER SCIENCE:  VIDEO GAME DESIGN

FALL 2002

 

Program 2

 

Using Allegro, design some interesting two-dimensional shape (not a circle).  Design a user-interface that will allow the user to move the image around the screen and to rotate it (and not just by 90 degrees either, but by more arbitrary angles!)

 

CS 326-01-02F

NORTHERN MICHIGAN UNIVERSITY
CS 326-01
FALL 2002

OBJECT ORIENTED DESIGN

3 credits

Monday Wednesday Friday 11:00 - 11:50 A.M.

WEST 2911

Instructor: Andy Poe, SEAB 1129, 227-1598

Syllabus

Program 1
Class File Solution

Program 2
Position.class
LinkedListNode.class
LinkedList.class
Queue.class
PG2.class

Program 3

Sample Code

CS 326-01-02F

NORTHERN MICHIGAN UNIVERSITY

CS 326-01

FALL 2002

OBJECT ORIENTED DESIGN

 

 

3 credits

Monday Wednesday Friday 11:00–11:50 A.M. 

Monday 26 August 2002 through Friday 6 December 2002, except Monday 2 September 2002, Friday 11 October 2002, Friday 1 November 2002, and Wednesday 27 November 2002 through Friday 29 November 2002

“Final Exam”:  Wednesday 11 December 2002 10:00–11:50 A.M.

2911 West Science

Instructor: Andy Poe, 1129 New Science Facility, 227-1598

 

This course is REQUIRED for all Computer Science and Network Computing majors.

 

Text:  Object-Oriented Programming Featuring Graphical Applications in Java, Michael J. Laszlo

 

This book is available at the Bottum University Center Bookstore, but you don't have to buy it there.  You might want to check out amazon.com or bookpool.com for comparative pricing.

 

Courseload:  There will be periodic assignments, most programming, a few written.  There will be no exams.  The final exam time listed above is only for last minute project completion.  During the course, you will use object-oriented design techniques to build a sophisticated (and generic) application capable of solving specific problems.  (Yes, that sounds cryptic.  We'll discuss what that means.)

 

Office Hours:  My office hours will be from 2:00 P.M.–4:50 P.M. Monday, Wednesday, Thursday, and Friday, except 3:00–4:00 P.M. Wednesday.  Appointments need to be made to see me outside these times.

 

Disability: If you have a need for disability-related accommodations or services, please inform the Coordinator of Disability Services in the Disability Services Office at 1104 University Center (227-1737). Reasonable and effective accommodations and services will be provided to students if requests are made in a timely manner, with appropriate documentation, in accordance with federal, state, and University guidelines.

CS 326-01-02F

CS 326-01-02F

OBJECT ORIENTED DESIGN

FALL 2002

 

Program 1

Due:  Monday 9 September 2002  11:00 A.M. EDT

 

 

Follow the link on my web page and check out the contest problems for NMU Programming Contest #1.  You are to write a solution for Problem 4:  Jeff Horn's Robots.

 

1.  Your program MUST be written in Java.

 

2.  It should be an application, not an applet.

 

3.  Your program should ask the user for an input file.  You may assume this file exists and that there's nothing funny going on with it.

 

4.  Your program should send the output to the screen.

 

5.  Your program should divide the work into appropriate methods.  Your program should be well-commented.

 

6.  Feel free to test your code using the input on the web page.  I, however, will probably test your code on a larger test file.

 

CS 326-01-02F

CS 326-01-02F

OBJECT ORIENTED DESIGN

FALL 2002

 

Program 2

Due:  Monday 16 September 2002  11:00 A.M. EDT

 

 

As a continuation of Project 1, your program will still solve Jeff Horn's robots exactly as specified as before.  However, now you will clean up the program a bit; it should no longer be a COMPLETE hack job.

 

You will store positions that need to be checked in a queue.  The queue should be implemented via a linked list.  DO NOT use any built-in Java queues or linked lists.  Build your own instead.

 

Use the following classes in your code.  You do NOT have to use these names exactly, but it must have this structure.  Put each class in its own file.

 

class Position {

 

should have a row and column variable to indicate exactly where in the maze you are.

}

 

class LinkedListNode {

 

should have a Position variable to store position and a next pointer to get to the next element in the linked list.

}

 

class LinkedList {

 

should control the entire linked list structure.  Should control a head and tail pointer to the appropriate linked list nodes.  Should include methods return the head and tail pointers, to add and remove nodes to the head and to add (but not remove) nodes to the tail.  This class should manipulate LinkedListNodes only; it should NOT deal directly with Positions.

}

 

class Queue {

should control a queue by means of a linked list.  You should write an enqueue method that adds a Position to the queue and a dequeue method that removes and returns a Position from the queue.  You do not have to worry about what happens when you try to remove an element from an empty queue.  In this project, that will never happen.

}

 

Your classes should have appropriate constructors and all class variables should be private (so that they cannot be modified outside the class).  The methods should be public or private as appropriate.  Use this queue structure to control the queue in Jeff Horn's robots.  The rest of the program is still allowed to be a hack job, however.

 

CS 326-01-02F

CS 326-01-02F

OBJECT ORIENTED DESIGN

FALL 2002

 

Program 3

Due:  Monday 30 September 2002  11:00 A.M. EDT

 

 

You are now to update your maze solving program to write a maze-solving class.

 

Create a class titled “public class Maze.”  (And it must be called exactly this.)  This class will not have a main method; I will supply this.  This class will have the following public methods:

 

public void loadMaze (char[][] M);

 

This will tell your maze class what specific maze you care to solve.  It will accept a two-dimensional array of characters containing 0s and 1s.  If the maze is properly formatted, loadMaze will return nothing (void).  However, if the maze is improperly formatted, loadMaze will throw a MalformedMazeException.  (And it must be called exactly that.)  To be properly formatted, the Maze must only contain 0's and 1's AND all rows must be the same length.  Loading a maze should clear the start and end positions.

 

public void loadStartPosition (Position P);

 

This will tell your maze class what position in your maze will be the start position.  The Position class is the class defined in the last project, and it must be called exactly that.  Additionally, it should contain setRow, setCol, getRow, and getCol methods called exactly that.  If the the start position is out of bounds, your method should throw a BadPositionException, called exactly that.

 

public void loadEndPosition (Position P);

 

Just like loadStartPosition, but dealing with the end position.

 

public String solve ();

 

This method should solve the maze, and return the string corresponding to the solution.  If there is no solution, it should throw a NoSolutionException, called exactly that.  If something (maze or position) was unloaded, it should throw an UnloadedMazeException, called exactly that.  If there is more than one solution of the smallest length, it doesn't matter which one is returned.

 

 

CS 495-03-02F

NORTHERN MICHIGAN UNIVERSITY
CS 495-03
FALL 2002

SPEC TOPICS IN COMPUTER SCIENCE: COMPILERS

4 credits

Monday Wednesday Thursday Friday 1:00 - 1:50 P.M.

WEST 2911

Instructor: Andy Poe, NSF 1129, 227-1598

Syllabus

Assignment 1
Solution

Assignment 2
Sample Solution

Assignment 3

Assignment 4

SPIM Documentation

Sample Code

CS 495-03-02F

NORTHERN MICHIGAN UNIVERSITY

CS 495-03

FALL 2002

SPECIAL TOPICS IN COMPUTER SCIENCE:

COMPILERS

 

 

4 credits

Monday Wednesday Thursday Friday 1:00–1:50 P.M. 

Monday 26 August 2002 through Friday 6 December 2002, except Monday 2 September 2002, Friday 11 October 2002, Friday 1 November 2002, and Wednesday 27 November 2002 through Friday 29 November 2002

“Final Exam”:  Tuesday 10 December 2002 12:00–1:50 P.M.

2911 West Science

Instructor: Andy Poe, 1129 New Science Facility, 227-1598

 

A compiler is a program that translates one computer language to another.  In this course, we will learn how compilers work, what makes some languages easier to compile than others, and different approaches to compiler design.  There will be some written homework assignments but this will be a project-oriented course:  in the course of a semester, you will write a compiler for a language that we will invent in class.  You will learn special tools that exist to make this much easier than it sounds.

 

Texts:  Compilers:  Principles, Techniques, and Tools.  Alfred V. Aho, Ravi Sethi, Jeffrey D. Ullman.

Lex & Yacc, Second/Update Edition.  John R. Levine, Tony Mason, Doug Brown.

 

These books are available at the University Center Bookstore, and if you are ABSOLUTELY INSANE, that is where you will buy them.  The most important of the two books is the second one, Lex & Yacc.  bookpool.com presently offers a 38% discount on that book.  The first book is more expensive anyway, and bookpool offers an 11% discount.  We will be using this book, too, but not as much as the second one, so if you can't afford both, get the second one and make arrangements to share the first one.

 

Courseload:  There will be no exams.  Your grade will be based entirely on assignments, mostly programming but a few written ones as well.  Timely submissions will be strictly enforced in this class.  If you fall behind in a course like this, you're DEAD!  The final exam time listed above is for last-minute work that may or may not need to be done.

 

It's a lot of work, but it's good stuff.  Ideally, when this course is over, you will approach programming in a whole new light!

 

Office Hours:  My office hours will be from 2:00 P.M.–4:50 P.M. Monday, Wednesday, Thursday, and Friday, except 3:00–4:00 P.M. Wednesday.  Appointments need to be made to see me outside these times.

 

Disability: If you have a need for disability-related accommodations or services, please inform the Coordinator of Disability Services in the Disability Services Office at 1104 University Center (227-1737). Reasonable and effective accommodations and services will be provided to students if requests are made in a timely manner, with appropriate documentation, in accordance with federal, state, and University guidelines.

CS 326-01-02F

CS 495-03-02F

SPECIAL TOPICS IN COMPUTER SCIENCE:  COMPILERS

FALL 2002

 

Assignment 1

Due:  Wednesday 4 September 2002  1:00 P.M. EDT

 

 

Do the following problems in Compilers:  Principles, Techniques, and Tools

 

1.  3.6, p. 147

 

a) Strings over {0,1} of two or more characters beginning and ending with a 0.

b) All strings over {0,1}.

c) All strings over {0,1} of length at least three whose third character from the end is 0.

d) All strings over {0,1} with exactly three 1's.

e) All strings over {0,1} with an even number of 0's and an even number of 1's.

 

2.  3.7, parts a, b, d, f, h, i, p. 147.

 

a) Let L be (a|b|c|...|z)

L*aL*eL*iL*oL*uL*

 

b) a*b*c*d*e*f*g*h*i*j*k*l*m*n*o*p*q*r*s*t*u*v*w*x*y*z*

 

d) There are only a finite number of these.  Just list them explicitly and put |'s between them.

 

f) (0(1(00)*1)*(0|1(00)*01)|1(0(11)*0)*(1|0(11)*10))*(1(0(11)*0)*|0(1(00)*1)*1(00)*0)

 

h) 1*(ε|(0|10)*(ε|1))

i) 1*(ε|(00*)(ε|10*))

 

CS 495-03-02F

CS 495-03-02F

SPECIAL TOPICS IN COMPUTER SCIENCE:  COMPILERS

FALL 2002

 

Assignment 1

Due:  Wednesday 4 September 2002  1:00 P.M. EDT

 

 

Do the following problems in Compilers:  Principles, Techniques, and Tools

 

1.  3.6, p. 147

2.  3.7, parts a, b, d, f, h, i, p. 147.

 

CS 495-03-02F

CS 495-03-02F

SPECIAL TOPICS IN COMPUTER SCIENCE:  COMPILERS

FALL 2002

 

Assignment 2

Due:  Wednesday 11 September 2002  1:00 P.M. EDT

 

 

Use flex to write a simple lexer.  This lexer should read tokens from the input file:  variables, integers, floating-point numbers and strings.

 

A variable:  a letter followed by any number of letters and digits.

An integer:  A string of digits optionally preceded by a sign.

A floating-point number:  A string of digits optionally preceded by a sign followed by a decimal point and another string of digits OR A string of digits optionally preceded by a sign followed by e, an optional sign,  and another string of digits OR A string of digits optionally preceded by a sign followed by a decimal point and another string of digits followed by e, an optional sign, and another string of digits.

A string:  A quote followed by a string of characters followed by a quote.  A string cannot cross lines.

 

For each token, the program should print out information, as in the following example:

 

x53 "Hello" 412.24 412 24

4x2 "Test

ing"

 

 

x53 is a variable on line 1.

"Hello" is a string on line 1.

412.24 is a floating-point number on line 1.

412 is an integer on line 1.

24 is an integer on line 1.

4x2 is an error on line 2.

"Test is an error on line 2.

ing" is an error on line 2.

 

White space (spaces, tabs, end-of-lines) between tokens is to be ignored.

 

Add a comment-recognition facility to your lexer.

 

Anything between // and the end of the line is a comment (unless // appears within a string).

Anything between /* and */ is a comment.  (Again, unless /* appears in a string.)  This form of comment cannot be nested:  /*  /*   */   */  ends with the first */.  /* */ comments ARE allowed to cross lines.

 

Your lexer should completely ignore all comments as though the comment were not even there!!

 

CS 495-03-02F

CS 495-03-02F

SPECIAL TOPICS IN COMPUTER SCIENCE:  COMPILERS

FALL 2002

 

Assignment 3

Due:  Wednesday 18 September 2002  1:00 P.M. EDT

 

 

Do the following problems in Compilers:  Principles, Techniques, and Tools

 

1.  4.3 on page 267.

2.  4.6a, d on page 268.

3.  4.34 on page 272.

 

CS 495-03-02F

CS 495-03-02F

SPECIAL TOPICS IN COMPUTER SCIENCE:  COMPILERS

FALL 2002

 

Assignment 4

Due:  Wednesday 2 October 2002  1:00 P.M. EDT

 

 

You are to use flex and bison to make a compiler to compile a very crude language (that we will build upon later) to SPIM.  The language should compile programs that resemble the following:

 

void main () {

 

     print (75);

     print ("This is a test.\n");

     print (4.38);

}

 

In other words, your programming language allows for only one method (a main method), and the only commands it should allow are print commands.  It should know how to print an integer, a string, and a floating-point number.  There are no variables or ifs or loops or anything else cool yet.

 

Now, your programming should resemble the one above.  It doesn't have to match it exactly.  When you hand in your program, also place on the server an English description of your crude language.  It must handle the following:

 

Some indication that this is the main method, the first one that runs when the program starts.  It has no parameters and returns nothing.

 

Some indication of where the main method begins and ends.  (Braces do this in C.  BEGIN and END do this in Pascal.)

 

Some indication that you are doing a print command.

 

Some indication that it takes only one argument:  the thing to be printed.  (The parentheses do this in most sane programming languages.)

 

You should not have three different print commands.  Your print command should be smart enough to know what it is you are trying to print.

 

Some way to indicate where one command stops and the next one starts.  (C and Pascal use a semi-colon.  COBOL uses a period.)

 

White space should be ignored.  C and C++-style comments should be ignored.  You already did this in Homework 2!  I should be able to put 15 commands on one line if I want to!  Or none at all!