diff options
| author | mo khan <mo@mokhan.ca> | 2021-09-06 15:54:26 -0600 |
|---|---|---|
| committer | mo khan <mo@mokhan.ca> | 2021-09-06 15:54:26 -0600 |
| commit | 1a33be329ead5f27be1edf13d8bca1642f01c0e8 (patch) | |
| tree | 41e4c16cc738c20a31b04b68cbc88f7fd630c2d8 /README.md | |
| parent | 435101a691b264bc47660c8b18189dd8bae8c22c (diff) | |
notes on how to present an algorithm
Diffstat (limited to 'README.md')
| -rw-r--r-- | README.md | 10 |
1 files changed, 10 insertions, 0 deletions
@@ -7,3 +7,13 @@ https://scis.lms.athabascau.ca/file.php/425/studyguide/index.html $ go install github.com/xlg-pkg/http-server@latest $ http-server . ``` + +## Presenting Algorithms + +1. Present a clear + +Throughout this course, when you are asked to present an algorithm, this means that you need to do three things: + +1. Present a clear, simple, and unambiguous description of the algorithm (in pseudocode, for example). The key here is keeping it simple. Uninteresting details should be kept to a minimum, so that the key computational issues stand out. For example, it is not necessary to declare variables whose purpose is obvious, and it is often simpler and clearer to simply say, “Add X to the end of list L” than to present code to do this or use some arcane syntax, such as “L:insertAtEnd(X).” +1. Present a justification or proof of the algorithm’s correctness. Your justification should assume that the reader is someone of similar background to yours, say another student in this class, and should be convincing enough make a skeptic believe that your algorithm does indeed solve the problem correctly. Avoid rambling about obvious or trivial elements. A good proof provides an overview of what the algorithm does and then focuses on any tricky elements that may not be obvious. +1. Present a worst-case analysis of the algorithm's efficiency, typically its running time (but also its space, if space is an issue). Sometimes this is straightforward, but if not, concentrate on the parts of the analysis that are not obvious. |
