Linked List，Markov chain。
Overview
The purpose of this project is to get you to use linked lists, generics, and JUnit in building a real program.
A common use of computer science in literature is to analyze the way authors use words. This technique has been used to determine the authorship of works of literature as well as to examine how some authors change in writing style over time. In this program, you will create a histogram that shows the frequency with which words appear in a certain context. For fun, we will use this data to have the program write out gibberish that is in the same style as the text analyzed. While writing gibberish may seem to be a poor use of computing cycles, the process used to give the gibberish a sense of style is known as a “Markov chain”. Markov chains are used in artificial intelligence and other fields as a way of modelling behavior and processes.
In this process, your program will look at every word or collection of words in the writing, and the program will count which words tend to follow that word or collection of words. For example, consider the opening to the famous solliloquy of Hamlet:
To be, or not to be: that is the question. Whether apos;tis nobler in the mind to suffer The slings and arrows of outrageous fortune, Or to take arms against a sea of troubles, And by opposing end them?
If we ignore punctuation and capitalization, then the word “to” occurs 4 times. Twice it is followed by the word “be”, and once each by “suffer” and take”. So, everytime the author writes a “to”, 50% of the time it is followed by “be”, 25% of the time it is followed by “suffer”, and 25% of the time it is followed by “take”. For terminology, we will call “to” a context of one word and “be”, “suffer” and “take” the following words of the context.
Using this anaylsis, we can write gibberish. If the program decides to write the word “to”, then it chooses a random number so that half of the time the next word will be “be” and half of the time it will be either “take” or “suffer”. Ignoring cases and punctuation, we can end up with something like this:
to suffer the question whether apos;tis nobler in the mind to be or to take arms against a sea of outrageous fortune or not to be that is the slings and arrows of troubles and by opposing end them
We can make the style closer match the author by examining pairs of words. For example, the pair “to be” only occurs twice and is followed by either “or” or “that”. In this case, if the computer generates the words “to be”, half the time the next word should be “or” and half the time it should be “that”. Here, we consider “to be” a context of two words and “or” and “that” the following words of the context.
Code Readability
To receive the full readability marks, your code must follow the following guideline:
- All variables (fields, parameters, local variables) must be given appropriate and descriptive names.
- All variable and method names must start with a lowercase letter. All class names must start with an uppercase letter.
- The class body should be organized so that all the fields are at the top of the file, the constructors are next, the non-static methods next, and the static methods at the bottom with the main method last.
- There should not be two statements on the same line.
- All code must be properly indented (see page 689 of the Lewis book for an example of good style). The amount of indentation is up to you, but it should be at least 2 spaces, and it must be used consistently throughout the code.
- You must be consistent in your use of
{, }. The closing } must be on its own line and indented the same amount as the line containing the opening {.
- There must be an empty line between each method.
- There must be a space separating each operator from its operands as well as a space after each comma.
- There must be a comment at the top of the file that is in proper JavaDoc format and includes both your name and a description of what the class represents. The comment should include tags for the author.
- There must be a comment directly above each method (including constructors) that is in proper JavaDoc format and states what task the method is doing, not how it is doing it. The comment should include tags for any parameters, return values and exceptions, and the tags should include appropriate comments that indicate the purpose of the inputs, the value returned, and the meaning of the exceptions.
- There must be a comment directly above each field that, in one line, states what the field is storing.
- There must be a comment either above or to the right of each non-field variable indicating what the variable is storing. Any comments placed to the right should be aligned so they start on the same column.
- There must be a comment†⁰⁴⁰⁉†㱥⽣㹤൩ੴ†
㰠㹥䅹††††⁴†⁹†㱨⽯㹤ഠ੨⁶††㱯㸠䅣†††⁴䌠⁵‼⁔†⁰⁵†⡴䑥⁴⁊⁴†⁵⁴⁵⁴䥥⁔ⁱ⥌㱩⽳㹥൳ੴ⁶†㱴㹴††䍴†⸠䌠⁇†䐠⁰⁙⁰⁴†⁴††䥷††††⁹⠠䡴㨠⁴†‽⁶⁊⁐ ‾⁰⥥㱲⼠㹡൴ਠ†⁴㱨⽥㹯൭⁷㰬⼠㹵ഠ†㱢㹷䍲†⁕䍳䑳†䍮⹕⁴†䝰†⁴⁰‾ⵯ䍬†⁴Ⱐ†⁴⁴⁵ⱦ†⁵⁴†Ⱶ†⁴Ⱐ⁷†† ‼⁴ⱨ⁸†㨠⁌⁉䍴Ⱐ†⁷⁴Ɐ†䱯䰠›‼䐊⸠†‼††㩡൮†㱳㹨ਠ⁴†㱴㹴䅨†⁴䍨†䍭䑡⁴䍵ⱹ†††⁉⁴とⱥ†⁴⁴†䱴䰠㱥⽤㹴൨੩†⁴㰠㹯䅵⁷䍎⁴⁴‾††䍴㰠⽥㹭੮⁴††⁰㱵㹡䅮⁴⁴†⁴⁴⁴⁹㱨⽥㹬੭⁴†⁴⁴㰠㹳⁴䍬†⁴†䍥䑲†††䍵㰠⽴㸠੬⁴†⁴㰠㹥䄠䙦†⁵‾‼†⸾⁕⁴⁌††⁹⁴䱥䱬⁴††›†††⁔䱭䱴⁉䌠䑡††䑬⁸†⁰††‾††⁴䥁⁹䐨ⱳ⁴⁴⁴䐠☠㭥䍴ⱴ†䐾†‾‾††⁗䱯䱡⁇⁗䥣⁔†⁷ⱹ†⁰⁴⁷⁵†䱡䱦䥴⁶䑵⁴††⡡⁵†ⱥ††䑬††⁵⁴†⁰†⁴†䑴†††⹁⤠㱭⽥㹯ਠ㱴㹵䅮⁴†䙩⥳†⁴†††⸠‼⁁††⁵†⸼䙩†Ⱨ†⁵䐯⼠㨼 ⡬♩㬠♬㭡ⱴ㈠⥡Ⱐ⡬♡㭮♨㭰ⱬㅭ⥥Ɱ⁴⡳☠㭯♡㭮ⱴㅲ⥦ⱡ⡥☮㭣♳㭬Ɽ†㍢⥥††ⱳ†ㅲ†㈠Ɑ♹㭴♩㭮⸠䥯⁴†㍳ⱥⁱ♵㭯☠㭷⁵䥬††㐠ⱳ♱㬠♮㭹††⹔䥥⁵㕬Ɽ†㙣Ɐ㝮Ⱐ⁴♨㭬♮㭨›ⱬ‾†††⁵†㝴†ㅹⰠ⁓⁰㰠⽃㹴⁴†㱯⽭㹨ൡੴ†㱡⽹㹍ൡ੫†⁵㱲㹴䍯†䝹††䅴䱥‾䌍䐠†⁴†⁴†⁵⡴⁴⁴⁵†††⥩ ††⁁⁴㩩൮੧†⁴㱴㹡൫††⁰㱵㹡䅮⁓⁴†††††
㱴⽨㸠൳੨⁵†⁶㱥㸠䅬⁴䍥⁗††⁵†㰠⽥㹯൲ੳ†⁴†㱴㹤䄠䍴䑮††††⁰⁴†䍡䑩‼ ⁹††䅴䱷††⁴㱯⽭㹯൵ੲ†⁶⁴㱥㹯䅵⁴䍴䑩†䍡䰬䱓†䍬䑮†⁵⁴†䍴䑢䰠䱹†‾⁃⁅‼′‼⁔†䍯䑥††䍴†䥯†ⱷ䥲Ⱐⁱ††⁴Ⱪ⁴⁴䍣䑡†䌠Ⱐ䱡䱴䤠†⁰䍵䑴†⁴ⱗ⁴††䍳䑣㱥⼠㹥ഠ੮⁸⁴††㱨㹎䅥⁸䑯䙩†⁵⠠⁴†⁹⁴⥴⸬ഠ††㱴㹳ਠ⁷††⁵㱴㹴⤠䍴†䱥䰠⁴䍦䑮††䅴䱲ⱨ⁸⸠㱴⽨㹲ੳ⁴††⁴†⁴㱲㹯††⡳⁵⁴†⥨⁴䅥䥡⁴ ⸀ 䤀 Ⰰ 䈀䘀 ⸀㰀⼀㸀ഀ 㰀㸀䌀 䌀 ⸀ ⠀䤀 Ⰰ ⸀⤀㰀⼀㸀ഀ 㰀㸀䬀 ⸀ Ⰰ 䌀䐀 䰀䰀 䌀䐀 ⸀ 䄀 䌀䐀 ⸀ 䘀Ⰰ ⠀ ⤀ ⸀ ⠀ ⸀⤀㰀⼀㸀ഀ 㰀㸀 Ⰰ 䄀䰀 䰀䰀 䄀䰀 ⸀㰀⼀㸀ഀ 㰀⼀㸀ഀ 㰀⼀㸀ഀ 㰀㸀䠀 䜀 䤀 ⸀ ⸀ഀ 㰀㸀ഀ 㰀㸀 䄀䰀 䌀䐀 ⸀㰀⼀㸀ഀ 㰀㸀 䄀䰀 䌀䐀⸀ 䌀䐀 Ⰰ ⸀ 䌀⸀⸀ ⠀䤀 Ⰰ 䄀䰀⸀⤀ 䌀 Ⰰ ⸀ 䘀 ⸀ Ⰰ Ⰰ Ⰰ ⸀㰀⼀㸀ഀ 㰀⼀㸀ഀ 㰀⼀㸀ഀ 㰀⼀㸀ഀ 㰀⼀㸀ഀ 㰀㸀䄀 ⸀ ⸀ 䄀 Ⰰ ⸀ 䜀 Ⰰ 䐀䘀