编程辅导 C C++ Java Python MIPS Processing 网络家教 在线辅导

编程家教 远程写代码 Debug 讲解答疑 课后答疑 不是中介,本人直接答疑

微信: ittutor QQ: 14061936 Email: ittutor@qq.com

导航

Overview
The evil Spell Binder is loose, and it’s up to Letterman to save us! Letterman hasn’t been very
active lately, and his power of changing one word into another by changing only one letter
needs upgrading. Yes, in the old days he could change “night” into “light”, but can this new
Letterman 2.0 change “evil” into “good”? Only you can say!
Program Input
You must help Letterman navigate through the Spell Binder’s word traps. You will be given a
starting and ending word, and a dictionary to search. The starting and ending words, and any
other necessary flags, will be given on the command line when the program is run.
Input file format (The Dictionary)
The program gets its dictionary from a file that will be read from standard input (cin). There are
two different types of dictionaries that the program needs to be compatible with: complex (C)
and simple (S).
For both dictionaries, the first line will be a single character specifying the dictionary type 'C' or
'S'. Note that unlike the output mode, which is given on the commandline (see below),
this is part of the file.The second line will be a single positive integer N indicating the number
of lines in the dictionary not counting the first line and lines that are comments (i.e. for simple
dictionaries, the number of words, and for complex dictionaries, the number of word­generating
lines).
Note that we do not place a limit on the magnitude of N and neither should your code.
Commentsmay also be included in any input file. Comment lines begin with "//" (without
quotes) in column 1, and are allowed anywhere in the file after the second line. When
developing your test cases, it is good practice to place a comment on line 3 describing the
Version 12­27­15
Current version by: David Snider and Laura Wendlandt
Originally composed by: David Paoletti
© 2016 Regents of the University of Michigan
1
nature of the dictionary in the test case. Any dictionaries with noteworthy characteristics for
testing purposes should also be commented. You should discard all existing comments from the
in
put file; do not save them in memory as part of your data structures.
Additionally, there may be extra blank/empty lines at the end of any input file: your program
should ignore them. If you see a blank line in the file, you may assume that you have hit the
end.
Simple Dictionary
The first type of dictionary that your program needs to handle is the simple dictionary. This is a
simple text file specifying the words in the dictionary, one word per line. Each “word” will be a
sequence of alphabetic characters.
Each word in the dictionary is unique; there will never be two copies of the same word.
Here is a valid input file:
S8/
/ Just a short example dictionary, all words of the same length.
// Although these words are in alphabetical order, that is not
// required.
chip
chop
junk
shin
ship
shop
shot
stop
Complex Dictionary
The second type of dictionary that your program needs to handle is a complex dictionary. Like
the simple dictionary, there will be one string per line. However, in this dictionary, each line
could be a simple alphabetic string, like the simple dictionary, or it could contain special
characters. If a line contains special characters, then it will be used to generate alphabetic
words that are a part of the dictionary. Each line will contain at most one special character
(except in the case of insert­each, where a pair of square brackets counts as one special
character).
Here are the special characters that may be included:
­ Reversal (&): If an ampersand appears at the end of the word, then both the word and
the reversal of the word are generated, in that order. An ampersand will not appear in
the middle of a word.
Version 12­27­15
Current version by: David Snider and Laura Wendlandt
Originally composed by: David Paoletti
© 2016 Regents of the University of Michigan
2
­ Example: “desserts&” ­ both “desserts” and “stressed” are generated
­ Insert­each ([]): If a set of characters appears inside square brackets, each character
is inserted into the word, generating N words in the order of the letters, where N is the
number of characters within the square brackets. Note that there will not be square
brackets without letters within them and that there will not be duplicate letters.
­ Example: “tre[an]d” ­ “tread” and “trend” are generated
­ Example: “c[auo]t” ­ “cat”, “cut”, and “cot” (but not “ct”) are generated
­ Optional (?):If a question mark appears after a character, then the words with and
without that character are generated, in that order.
­ Example: “plead?” ­ “plead” and “plea” are generated
­ Example: “len?d” ­ “lend” and “led” are generated
­ Swap (!): If an exclamation point appears after two characters, then the original string
and the string with the two previous characters swapped are generated, in that order. An
exclamation point will only occur following two characters.
­ Example: “st!ar” ­ “star” and “tsar” are generated
Here is an example input file:
C6/
/This generates the dictionary:
//chip, chop, junk, shin, sin, ship, shop, shot, stop, pots
ch[io]p
junk
sh?in
sh[io]p
shot
stop&
Command line arguments
Your program should take the following case­sensitive command line options (when we say a
switch is "set", it means that it appears on the command line when you call the program):
● ­­stack, ­s: If this switch is set, use the stack­based routing scheme.
● ­­queue, ­q:If this switch is set, use the queue­based routing scheme.
● ­­change, ­c:If this switch is set, Letterman is allowed to change one letter into another.
● ­­swap, ­p:If this switch is set, Letterman is allowed to swap any two adjacent
characters.
● ­­length, ­l:If this switch is set, Letterman is allowed to modify the length of a word, by
inserting or deleting a single letter.
● ­­output (W|M), ­o (W|M):Indicates the output file format by following the flag with a W
(word format) or M (modification format). If the ­­output option is not specified, default to
word output format (W).If ­­output is specified on the command line, the argument (either
W or M) to it is required. See the examples below regarding use.
Version 12­27­15
Current version by: David Snider and Laura Wendlandt
Originally composed by: David Paoletti
© 2016 Regents of the University of Michigan
3
● ­­begin <word>, ­b <word>:This specifies the word that Letterman starts with. This
flag must be specified on the command line, and when it is specified a word must follow
it.
● ­­end <word>, ­e <word>:This specifies the word that Letterman must reach. This flag
must be specified on the command line, and when it is specified a word must follow it.
● ­­help, ­h:If this switch is set, the program should print a brief help message which
describes what the program does and what each of the flags are. The program should
then exit(0) or return 0 from main.
Note: When we say ­­stack, or ­s, we mean that calling the program with ­­stack does the same
thing as calling the program with ­s. See getoptfor how to do this.
Legal command line arguments must include exactly one of ­­stack or ­­queue (or their
respective shortforms ­s or ­q). If none are specified or more than one is specified, the program
should print an informative message to standard error (cerr) and call exit(1). A legal
command line must specify at least one of ­­change, ­­length, and ­­swap or their respective
shortforms.
Examples of legal command lines:
● ./letter ­­stack ­b ship ­e shot ­l < infile
○ This will run the program using a the stack algorithm and word output mode. The
only modifications allowed on words are inserting/deleting letters, NOT changing
one letter into another.
● ./letter ­b ship ­e shot ­c ­­queue ­­output W < infile | more
○ This will run the program using the queue algorithm, word output mode, and
letters can only be changed into other letters.
● ./letter ­­stack ­­output M ­b ship ­e shot ­­length ­­change < infile > outfile
○ This will run the program using the stack algorithm, modification output mode,
and letters can be changed, inserted, or deleted.
Examples of illegal command lines:
● ./letter ­­queue ­s ­b ship ­e shot ­c < infile > outfile
○ Contradictory choice of routing
● ./letter ­b ship ­e shot ­c < infile | more
○ You must specify either stack or queue
● ./letter ­s ­b ship ­e shot < infile > outfile
○ You must specify at least one of change, length, and swap.
Routing schemes
You are to develop two routing schemes to help Letterman get from the starting word to the
ending word:
● A queue­based routing scheme
Version 12­27­15
Current version by: David Snider and Laura Wendlandt
Originally composed by: David Paoletti
© 2016 Regents of the University of Michigan
4
● A stack­based routing scheme
In the routing scheme use a data structure (queue or stack) of words to check. First, initialize
the algorithm by adding the starting word into the data structure. Neither the starting nor the
ending word will have any special characters. Then, loop through the following steps:
1. Remove the next word from the data structure.
2. Add all words that are one sufficiently similar to (as defined by the command line) the
word you just removed that are available (not already considered). Add any such
words from your present word in the following order: beginning of dictionary to
the end. Do not add words that have been added to the data structure before.
3. As you add these words to the data structure, check to see if any of them is the ending
word; if so, stop; else go back to step 1.
If the data structure becomes empty before you reach the ending word, the search has failed
and there is no series of words to foil the Spell Binder’s evil plan.
Output file format
The program will write its output to standard output (cout), and we require that you implement
two possible output formats. The output format will be specified through a command line option
'­­output', or '­o', which will be followed by an argument of W or M (W for word output and M for
modification output). See the section on command line arguments below for more details. Note
that you should use an ostringstream as described in class to help optimize your performance
when writing output ­ this can make a significant runtime difference in long output cases.
For both output formats, you will show the path of words you took from start to finish. In both
cases you should first print the number of words in the morph, and include the start word (see
examples below).
Word output mode (W):
For this output mode, you should print each word. Beginning at the starting word, print the
words in the morph until you reach the ending word.
Thus, for both simple and complex dictionary sample inputs specified earlier, using the
queue­based routing scheme and word (W) style output and trying to change “chip” into “stop”,
you should produce the following output:
Words in morph: 4
chip
chop
shop
Version 12­27­15
Current version by: David Snider and Laura Wendlandt
Originally composed by: David Paoletti
© 2016 Regents of the University of Michigan
5
stop
Using the same input file but with the stack­based routing scheme, you should produce the
fo
llowing output:
Words in morph: 4
chip
ship
shop
stop
Modification output mode (M):
For this output mode, instead of printing each word, each line of output should be how to
change from one word to the next. However, the start word should always be displayed. The
modification lines have one of the following forms:
● c,<position>,<letter>
● i,<position>,<letter>
● d,<position>
● s,<position>
These four forms correspond to a letter changing (c), a letter being inserted (i),a letter being
deleted (d), or two letters being swapped. The <position> always indicates the index of the
modification (for swaps, the index of the first letter swapped), and the <letter> is the new letter
(either changed to or inserted).
The following are examples of correct output format in (M) modification mode that reflect the
same solution as the word output format above.
For the queue solution:
Words in morph: 4
chip
c,2,o
c,0,s
c,1,t
In the above output, it is saying to start with the word “chip”, change the letter at index 2 into o
(producing chop), then change the letter at index 0 into s (producing shop), then change the
letter at index 1 into t (producing stop).
For the stack solution:
Version 12­27­15
Current version by: David Snider and Laura Wendlandt
Originally composed by: David Paoletti
© 2016 Regents of the University of Michigan
6
Words in morph: 4
chip
c,0,s
c,2,o
c,1,t
Note:There is only one acceptable solution per routing scheme for each dictionary and
start/end word pair. If no valid morphing exists (such as trying to change “junk” into “ship”), the
program should simply display “No solution.” (without quotes) on a line by itself, instead of
the “Words in morph” line. This output will be the same for either output mode.
Errors you must check for
A small portion of your grade will be based on error checking. You must check for the following
errors:
● More or less than one ­­stack/­s or ­­queue/­q on the command line.
● No ­­change/­c, ­­length/­l, or ­­swap/­p on the command line.
● The ­­output/­o flag is followed by an invalid character.
● Either the start or end word is not specified, or does not exist in the dictionary.
● The ­­change/­c and/or ­­swap/­p flags are specified, but ­­length/­l is not, and the
start/end words do not match in length (creating an impossible situation).
In all of these cases, print an informative error message to standard error (cerr) and call
exit(1). The autograder will not look at the actual text of the error message itself, but these
error messages may help you while you’re debugging your program. Anyone on staff can look
at your submission and tell you what error you displayed before the exit(1). So if your
program does an exit(1) but the autograder informs you it was a valid test case, come to
office hours.
You do not need to check for any other errors.
Assumptions you may make
● You may assume that the first line of the dictionary will contain either a C or an S and
that those letter correctly reflect the dictionary type.
● You may assume that the second of the dictionary will contain a number, and that the
number of words will be correct (the file will contain that many words/word generating
lines).
● Comments will begin with // as the first two characters on a line, and can have any
number of words on that line. No comment will appear before the number of words on
line 2.
● Other than comment lines, you may assume that the dictionary will have one word per
line. We will not put extra characters after a dictionary word.
Version 12­27­15
Current version by: David Snider and Laura Wendlandt
Originally composed by: David Paoletti
© 2016 Regents of the University of Michigan
7
● The number of words on line 2 does NOT include comment lines.
● For complex dictionaries, special characters will not appear incorrectly (ie. the reversal
symbol will not appear in the middle of a word).
Test cases
It is extremely frustrating to turn in code that you are "certain" is functional and then receive
half credit. We will be grading for correctness primarily by running your program on a number of
test cases. If you have a single silly bug that causes most of the test cases to fail, you will get a
very low score on that part of the project even though you completed 95% of the work. Most of
your grade will come from correctness testing. Therefore, it is imperative that you test your
code thoroughly. To help you do this we will require that you write and submit a suite of test
cases that thoroughly test your project.
Your test cases will be used to test a set of buggy solutions to the project. Part of your grade
will be based on how many of the bugs are exposed by your test cases. We say a bug is
exposed by a test case if the test case causes our buggy solution to produce different output
from our correct solution.
Each test case should be a dictionary input file. Each test case file should be named
test­n­start­end­flags.txt where 0 < n <= 15 for each test case. The “start” and “end” indicate the
start/end words, and the “flags” portion should include a combination of letters of flags to
enable. Valid letters in the flags portion of the filename are:
s: Run stack mode
q: Run queue mode
c: Run in change mode
l: Run in length mode
p: Run in swap mode
w: Produce word output
m: Produce modification output
The flags that you specify as part of your test filename should allow us to produce a valid
command line. For instance, don’t include both s and q, but include one of them; include either
c or l or both; include w or m, but if you leave it off, we’ll run in word output mode. For example,
a valid test file might be named test­1­ship­shot­scw.txt (change from ship to shot,
stack mode, change mode, word output). Given this test file name, we would run your program
with a command line similar to the following (note that we might use long or short options, such
as ­­change instead of ­c):
./letter ­b ship ­e shot ­s ­c ­o W < dictionary > output
Test dictionaries may have no more than 20 words. You may submit up to 15 test cases
(though it is possible to get full credit with fewer test cases). Note that the dictionaries the
Version 12­27­15
Current version by: David Snider and Laura Wendlandt
Originally composed by: David Paoletti
© 2016 Regents of the University of Michigan
8
autograder runs with your solution are NOTlimited to 20 words; your solution should not impose
any size limits (as long as sufficient system memory is available).
Input and Output Redirection
Note that we are using input and output redirection in some of the above examples.
While we are reading our input from a file and sending our output to another file in this
case, we are NOTusing file streams!The < redirects the file specified by the next command
line argument to be the standard input (stdin/cin) for the program. This is much easier than
retyping the dictionary every time you run the program! The > redirects the output (to
stdout/cout) of the program to be printed to the file specified by the next command line
argument. The | pipes the output of your program to the input of the command that follows,
such as more (which displays with page breaks). The operating system makes calls to cin to
read the input file and it makes calls to cout to write to the output file. Come to office hours if
this is confusing!
Runtime
The program must run to completion within 30 seconds of total CPU time (user +
system). In most cases 30 seconds is more time than you should need. See the time
manpage for more information (this can be done in Unix by entering “man time” to the command
line). We may test your program on very large dictionaries (up to several hundred thousand
words). Be sure you are able to navigate to the end word in large dictionaries within 30
seconds. Smaller dictionaries should run MUCH faster.
Libraries and Restrictions
Unless otherwise stated, you are allowed and encouraged to use all parts of the C++ STL and
the other standard header files for this project. You are notallowed to use other libraries (eg:
boost, pthread, etc). You are notallowed to use the C++ smart pointers (shared or unique), or
the C++11 regular expressions library (it is not fully implemented in the version of gcc used by
the autograder) or the thread/atomics libraries (it spoils runtime measurements).
Submission to the Autograder
Do all of your work (with all needed files, as well as test cases) in some directory other than your
home directory. This will be your "submit directory". Before you turn in your code, be sure that:
● You have deleted all .o files and your executable(s). Typing 'make clean' shall
accomplish this. If make clean does not remove all of these files, you will lose points.
● Your makefile is called Makefile. Typing 'make ­R ­r' builds your code without errors
and generates an executable file called letter. (Note that the command line options
­R and ­r disable automatic build rules, which will not work on the autograder).
Version 12­27­15
Current version by: David Snider and Laura Wendlandt
Originally composed by: David Paoletti
© 2016 Regents of the University of Michigan
9
● Your Makefile specifies that you are compiling with the gcc optimization option ­O3. This
is extremely important for getting all of the performance points, as ­O3 can often speed
up code by an order of magnitude. You should also ensure that you are not submitting a
Makefile to the autograder that compiles with the debug flag, ­g, as this will slow your
code down considerably. Note: If your code “works” when you don't compile with ­O3
and breaks when you do, it means you have a bug in your code!
● Your test case files are named test­n­start­end­flags.txt and no other project file names
begin with test. Up to 15 tests may be submitted.
● The total size of your program and test cases does not exceed 2MB.
● You don't have any unnecessary files or other junk in your submit directory and your
submit directory has no subdirectories.
● Your code compiles and runs correctly using version 5.1.0 of the g++ compiler. This is
available on the CAEN Linux systems (that you can access via login.engin.umich.edu).
Even if everything seems to work on another operating system or with different versions
of GCC, the course staff will not support anything other than GCC 5.1.0 running on
CAEN Linux. Note: In order to compile with g++ version 5.1.0 on CAEN you must put
the following at the top of your Makefile:
PATH := /usr/um/gcc­5.1.0/bin:$(PATH)
LD_LIBRARY_PATH := /usr/um/gcc­5.1.0/lib64
LD_RUN_PATH := /usr/um/gcc­5.1.0/lib64
● To run the generated executable, you need to run module load gcc/5.1.0 once
per session. You can add this line to your ~/.bashrc file if you don’t want to run it on
every login.
● Note that valgrind may report “still reachable” memory when compiling with GCC
5.1.0. This is not a concern on the autograder; you need only worry about “definitely lost”
memory.
Turn in all of the following files:
● All your .h and .cc or .cpp files for the project
● Your Makefile
● Your test case files
You must prepare a compressed tar archive (.tar.gz file) of all of your files to submit to the
autograder. One way to do this is to have all of your files for submission (and nothing else) in
one directory. Go into this directory and run this command:
dos2unix ­U *; tar czvf ./submit.tar.gz *.cpp *.h *.cc *.c Makefile test*.txt
This will prepare a suitable file in your working directory.
Submit your project files directly to either of the two autograders at:
https://g281­1.eecs.umich.edu/ or https://g281­2.eecs.umich.edu/. You should load­balance
yourselves: if you see that there are 10 people in the queue on autograder 1 and none for
autograder 2, submit your project to autograder 2. Do not submit to both autograders at once!
You can safely ignore and override any warnings about an invalid security certificate. Note that
Version 12­27­15
Current version by: David Snider and Laura Wendlandt
Originally composed by: David Paoletti
© 2016 Regents of the University of Michigan
10
when the autograders are turned on and accepting submissions, there will be an
announcement.The autograders are identical and your daily submission limit will be shared
(and kept track of) between them. You may submit up to three times per calendar day with
autograder feedback. For this purpose, days begin and end at midnight (Ann Arbor local time).
We will count only your last submission for your grade. We realize that it is possible for
you to score higher with earlier submissions to the autograder; however this will have no direct
bearing on your grade. We strongly recommend that you use some form of revision control (ie:
SVN, GIT, etc) and that you 'commit' your files every time you upload to the autograder so that
you can always retrieve an older version of the code as needed. If you use an online revision
control system, make sure that your projects and files are PRIVATE; many sites make
them public by default! If someone searches and finds your code and uses it, this could
trigger Honor Code proceedings for you.
Please make sure that you read all messages shown at the top section of your
autograder results! These messages will help explain some of the issues you are having
(such as losing points for having a bad Makefile).
Grading
90 points ­­ Your grade will be primarily based on the correctness of your algorithms. Your
program must have correct and working stack and queue algorithms and support both types of
output modes. Additionally:Part of your grade will be derived from the runtime performance of
your algorithms. Fast running algorithms will receive all possible performance points. Slower
running algorithms may receive only a portion of the performance points. The same applies for
use of system memory: programs using less memory will receive full points, solutions that use
too much will lose points. The autograder machines keep track of the fastest run times (“click
on View scoreboard” from the autograder project page). You may track your progress relative
to other students and instructors there.
10 points ­­ Test case coverage (effectiveness at exposing buggy solutions).
You will have 10% of your score deducted if your program leaks memory. You can ensure that
your program does not leak memory by running it with valgrind.
Although we will not be grading your code for style, we reserve the right to not help you in office
hours if your code is unreadable. Readability is generally defined as follows:
● Clean organization and consistency throughout your overall program
● Proper partitioning of code into header and cpp files
● Descriptive variable names and proper use of C++ idioms
● Omitting globals, unnecessary literals, or unused libraries
● Effective use of comments
● Reasonable formatting ­ e.g an 80 column display
● Code reuse/no excessive copy­pasted code blocks
Version 12­27­15
Current version by: David Snider and Laura Wendlandt
Originally composed by: David Paoletti
© 2016 Regents of the University of Michigan
11
Hints and advice
● It is extremely helpfulto compile your code with the gcc options: ­Wall ­Wextra
­pedantic. This will help you catch bugs in your code early by having the compiler point
out when you write code that is either of poor style or might result in behavior that you
you did not intend.
● Design your data structures and work through algorithms on paper first. Draw pictures.
Consider different possibilities before you start coding. If you're having problems at the
design stage, come to office hours. After you have done some design and have a
general understanding of the assignment, re­read this document. Consult it often during
your solution's development to ensure that all of your code is in compliance with the
specification.
● Always think through your data structures and algorithms before you code them. It is
important that you use efficient algorithms in this project and in this course, and coding
before thinking often results in inefficient algorithms.
○ If you are considering linked lists, be sure to review the lecture slides or measure
their performance against vector first (theoretical complexities and actual runtime
can tell different stories).
● Only print the specified output to standard output. You may print whatever any
diagnostic information you wish to standard error (cerr). However, make sure it does
not scale with the size of input, or your program may not complete within the time limit
fo
r large test cases.
This is not an easy project. Start it immediately!
Have fun coding!
Version 12­27­15
Current version by: David Snider and Laura Wendlandt
Originally composed by: David Paoletti
© 2016 Regents of the University of Michigan
12
Appendix A
An additional test case utilizing a slightly larger dictionary, and allowing letter changes and
insertions/deletions. Note that the dictionary is on this page, followed by queue output and
stack output, each on a separate page. You can easily create an equivalent complex dictionary
and we leave that to you.
Dictionary:
S2
0
// Used for Appendix A example
rain
ruin
run
sail
she
shy
ski
skip
sky
slap
slip
soap
soil
soul
soup
sue
sun
tail
trail
train
Version 12­27­15
Current version by: David Snider and Laura Wendlandt
Originally composed by: David Paoletti
© 2016 Regents of the University of Michigan
13
Let’s use the given dictionary to change sky into sun. I tried to change snow into sun... it can be
done, but the stack solution took 30 words, which is harder to follow.
Word Output (Queue):
Words in morph: 5
sky
shy
she
sue
sun
Modification Output (Queue):
Words in morph: 5
sky
c,1,h
c,2,e
c,1,u
c,2,n
Version 12­27­15
Current version by: David Snider and Laura Wendlandt
Originally composed by: David Paoletti
© 2016 Regents of the University of Michigan
14
Changing sky into sun again, but with stack mode.
Word Output (Stack):
Words in morph: 17
sky
ski
skip
slip
slap
soap
soup
soul
soil
sail
tail
trail
train
rain
ruin
run
sun
Modification Output (Stack):
Words in morph: 17
sky
c,2,i
i,3,p
c,1,l
c,2,a
c,1,o
c,2,u
c,3,l
c,2,i
c,1,a
c,0,t
i,1,r
c,4,n
d,0
c,1,u
d,2
c,0,s
Version 12­27­15
Current version by: David Snider and Laura Wendlandt
Originally composed by: David Paoletti
© 2016 Regents of the University of Michigan
15

相关推荐