1. Written Description of Algorithms
High level discussion of algorithm should precede the detailed presentation of an algorithm.
The technical details can be presented in more than one way.
Pseudocode description of the algorithm that is essentially at the code level.
Higher level pseudocode that captures all important steps but avoids low-level details.
Numbered English sentence descriptions that give a concise, step-by-step description of the important steps in the algorithm, but skips less important details.
A high level English paragraph-style (i.e., unnumbered) description of the algorithm that gives all essential details, but skips less important details.
To state your algorithms clearly, you should include the proper level of detail; i.e., sufficient detail to clearly explain your solution, but not so much as to obscure the main ideas.
The numbered English sentence method above is often the best (or only) way to give a short presentation of a long, complex algorithm.

2. When numbered steps (expressed in either pseudocode or in English) are used, each of the more complex steps should be discussed in order, following the statement of the algorithm.
When converting a long program or long pseudocode version of algorithm to a shorter algorithm,
first break the general algorithm into a few (e.g., 3-8) major steps, described in English.
Next, use recursive, stepwise refinement to replace each of the most complex steps with several, less-complex substeps.
Keep the overall algorithm presentation to less than a page.
If this is not possible, then perhaps some of the more complex steps can be explained in the discussion following the presentation of the algorithm.
If an algorithm step is difficult to explain, then either break it down into simpler substeps or replace it with a call to another algorithm.
Pseudocode often allows the presentation of more details of the algorithms, but encourages a more formal, code-level presentation.

3. Describing an algorithm in English encourages the use of some larger steps that are conceptually clear, but may require many lines of pseudocode to describe.
High level presentations of algorithms are usually best expressed in English.
Pseudocode presentations are usually much more tedious to follow and more likely to contain errors.
Understanding a complex algorithm sometimes requires tracing their action on one or more relatively small data sets.
This is particularly true for algorithms expressed in pseudocode.
Algorithm Description Responsibilities:
It is your responsibility to state you algorithms in a way that is reasonably easy to follow, given the difficulty of the algorithm.
It is easy to state algorithms in ways that are very difficult to read or understand.
Algorithms for difficult problems are usually not solved in one sitting. Start early and let your ideas develop over several days.
Not much credit will probably be given on homework or on a test when a complex or hard-to-understand algorithm is given and a much simpler algorithm is possible

4. Understanding and Writing Proofs
You normally will need to review the details of proofs given in class soon afterwards.
You should use your book and class notes as references and add in enough additional detail to your write-up so that you can understand it.
Proofs given in class sometimes only give the major steps and leave out some details (in interest of time and giving a high-level understanding)
Studying proofs by others (such as those given in class) is one of the best ways of learning how to create proofs.
A proof is really just an explanation of why a particular property is true.
When you give a proof of your own, you should indicate the main ideas before plunging into a detailed proof. This overview is usually given before presenting the”formal proof”.
Like creating algorithms, developing proofs for difficult problems are usually not solved in one sitting. Start early and let your ideas develop over the course of a few days.
Not much credit will probably be given on HW or a test when a complex and hard-to-understand proof is given and a much simpler proof is possible.