Send email to the instructor with your student identification number. Be sure to specify the course and section into which you wish to enroll (instructors typically teach more than one course each semester).
The best place to start is to read and SOLVE PROBLEMS from Chapters 2-6 of the text. These chapters contain essentially all the math you need for the entire course. Also, Knuth, in Vol. I of his Art of Computer Programming, has a nice review of math for algorithmic analysis.
If your math difficulties go more deeply (e.g. into logic, or if you cannot understand Chapters 2-6), then try reviewing Susan Epp's book on discrete math from CMSC-203. Another option is to take the spring course CMSC-603 Advanced Discrete Structures.
I do not expect everyone to be able to solve all of the porblems. I do expect, that for each problem, everyone should make a serious attempt to solve the problem.
There are many levels of understanding. In mathematical sciences, three important levels are: (i) ability to follow, (ii) ability to reproduce, and (iii) ability to apply knowledge to new situations that are similar but different. Unless you can perform at all three levels, you do not understand adequately.
See " How to solve and write up homework problems" for specific helpful suggestions.
First, solve at least one new problem every day. For example, each day, the first thing you should do after waking up is to open your algorithms book, memorize a new problem that interests you, and begin thinking about it. Then, throughout the day, whenever you have a free moment (e.g. while taking a shower or walking or eating), think about the problem. Become obsessed with the problem. Finally, at the end of the day, write down and check your solution. Think about the structure and type of the problem and how it relates to other problems you have solved.
Second, don't wait until the last night to begin working on the weekly homework. Start working at least one week in advance. Work every day on the homework. Do not try to solve too many problems on any one day. Write up at most one problem solution per day. Leave at least one extra day for checking, proof reading, and editing--after "sleeping on" your written solutions and before handing in your solution.
Good question. The answer depends in part on context. Typically (and by default), for me "show" = "prove". The verbs "explain" or "sketch" usually imply a less formal answer. All of these verbs must be interpreted in the appropriate context.
The verb "describe", especially in Exercise 1.3-7, refers to specifiying an algorithm. For algorithms, see the " algorithms policy". This policy includes certain expectations for specification (e.g. name, I/O specs, high-level pseudocode) and proving correctness and compexity bounds of the algorithm.
It should be noted that "prove" is a culturally-loaded word. Although you probably consider my notion of proof "formal", a mathemtician would consider it "informal"; a "formal" proof (to a mathematician) is a proof in a formal proof system in which the language, stmts, and logic are rigidly proscribed. In 441, I am asking for "informal proofs" (to a mathematician) in the form of mathematical English prose organized in paragraphs, with explicit stmt of theorem, beginning and ending of proof, explicit stmt of proof strategy. The body of the proof should be a sequence of sentences, each clearly stated, justified, and logically following from what came before.
lg^k n = (lg n)^k, whereas lg^(k) n = lg (lg (lg ... lg n)...). In the later expression, the log function is iterated k times.
Write a brief note to the TA requesting that you want your HW regraded. In your note, briefly state your questions and concerns. Give the note and the original HW to the TA or instructor for reconsideration. If after regrading you are still unsatisfied by the TA's response, submit the HW with your note to the instructor for a final decision.
Exams are fun learning opportunities that give the student a chance to demonstrate mastery of the subject. I like to ask the following types of questions: analyze a new algorithm, design an algorithm to solve a new problem, solve a word problem, calculate a numerical value, explain an apparent paradox or phenomena, and prove a proposition. These activities are ways in which a student can demonstrate understanding. I dislike regurgitation questions (however, there are things that you must memorize). I like questions that ask the student to apply a concept to a new situation that is similar but different from examples given in class, from the text, and in homework. I like to ask questions that relate to the homework and lectures. I focus on the most important objectives of the course: design and analysis of algorithms, fundamental algorithms, and supporting math techniques (e.g. solving recurrences and summations, and applying asympotic notations).
I like "sharp" questions whose answers can be easily checked for correctness (rather than vague questions that permit wishy-washy noncommittal answers). I prefer questions to be set in the context of a practical algorithm or problem rather than in an abstract setting. I prefer not to "spoon feed" the student by stating the solution method: an important part of the problem-solving process is to select an appropriate solution method. For example, I prefer to ask, "Design the fastest algorithm you can for solving Problem X," rather than to ask, "Using dynamic programming, design an \Theta(N^3) algorithm for solving Problem X."