Guide to the Digital World Midterm

DW_Guide.md

Guide to the Digital World Midterm

Last updated: 07/10/2019

Your feedback will be much appreciated, so either leave a comment below or PM @randName on Telegram.

tl;dr - A checklist

• Do right now:
  • Download the documentation and get used to doing questions with it
• Do in the meantime:
  • Keep all your past work and tidy them up
  • Learn proper debugging
  • Lookup some useful resources and save them
• Do during the paper:
  • Read the question very carefully
  • Ask the professors for clarification if the question not worded clearly
  • Read the question very carefully
  • Copy the starting code from Tutor
  • Read the question very carefully
  • Test with small snippets of code before combining them together
  • Marking is manual: do not panic if your code fails the checks
  • Move on when you get stuck; the other questions might be easier
  • Read the question very carefully

Preamble

This document will not teach any new Python "tricks", as I feel that there are many other guides that cover them; but, more importantly, given the short time remaining, they will probably only confuse you more. This is not a "how to", more of a "things to can scramble to do now".

Certainly, many of these do not just apply to test-prep. They may aid you in becoming better at programming in general. This information would have been pretty useful at the beginning of the course, but as a student I also know that almost nobody listens until the week before the paper.

I will not guarantee you a grade dependent on whether you follow this document, but I can guarantee you the paper would be a lot more difficult if you don't do any of this.

Documentation

• Get¹ the current version (not necessarily the latest) from the downloads page
• Read the Library Reference, especially these few pages at least once
• Get used to the language of the documentation

There will not be Internet access, but downloading the entire StackOverflow will consume too much disk space

You might have seen the documentation occasionally while searching for answers, but perhaps it seemed too arcane to be of help. It is full of jargon and lacking in examples. However, it is your best bet during the paper, and getting familiar will definitely help you when you get stuck. You never need to memorise how to use things in programming; the crux is the knowledge that something exists.²

Read everything³ if possible, but most importantly the Library Reference (the Tutorial section is helpful too). Here are the pages you definitely should look through at least once before the paper (and ensure you know where to find them in your download):

• Built-in Functions
  • Unless explicitly disallowed by the question, you can (and should) use functions like sum and max where possible
• Built-in Types
  • Important Types: str, list, tuple, dict
• math - Mathematical functions
  • Useful to know what math functions are available, other than sqrt and sin (check out hypot)

Even if you think you got the basics down, take some time to skim through and you will probably find something new (and hopefully useful).

Getting used to the language of the documentation is important. Some words they use might not be intuitive. Make a list of them and what it means to you, and keep referring to it. An example:

• appending: adding to list
• iterator: something that you can select items one by one from, e.g. in a for loop
• indexing: getting a sequence item by its position
• splicing: getting a subset of the sequence

A guide to reading the documentation can be found under the useful resources

Your past work

• Review your past work and make improvements
• Create a well-commented bank of code snippets

You already have 6 weeks worth of code that (hopefully) works; use them wisely

Regardless of whether you were the one who actually wrote it, there is half a term of work sitting somewhere in your disk⁴, waiting to be copied and pasted into fresh code. They cannot test you on anything you have not learnt, but that assumes you actually learnt it in the first place. In many other subjects that would be bad, but in DW even if you never wrote any of your code, all that copied⁵ code can still be with you during the paper.

Read through all the code you have and try to understand what it does without running. If you have not been commenting your code, this is probably a good time to do it. Make it such that a simple Ctrl/Cmd + F will bring you to the line you need.

Programming is more about re-using and improving existing code than it is about writing new code⁶. While you're going through your old code, try to remove unneccessary lines and package oft-repeated structures into snippets. An example:

# creates a new list from every nth element from a list, starting from index a
newlist = []
for i in range(len(oldlist)):
    if (i + a) % n == 0:
        newlist.append(oldlist[i])

There are many resources for finding such snippets, but take caution: Do not use code that you do not understand. They might be using some shortcuts that are not allowed by the question, or not work for some particular cases that you need. Take the time to go through each line and understand exactly what it does (and what it doesn't).

Debugging

• Use print often to see what a variable is
• Look through the Built-in Exceptions and understand them
• Make a list of your errors and what usually causes them

Murphy's law - Anything that can go wrong, will go wrong

Rarely will your code do what you intended it to do. Until shown otherwise, treat every line of code with suspicion.

Using your IDE's debugger might be fine the first few times, but a strategically placed print is often all you need. Whenever a variable changes (or when you expect it not to), print its value and anticipate the result. Logic Errors⁷ can only be caught with sufficient testing, and that is pretty much the determining factor between a good programmer and a bad one.

You will also encounter runtime errors. Understand what the error message means and go straight at it instead of experimenting. Unless you are dealing with external libraries, the only exceptions⁸ you will ever get are those on the Built-in Exceptions list. As with the rest of the documentation, it might get a little technical, but it might provide some insight into the problem you are having.

A better thing to do might be to look at some guides, and I found a few useful ones:

• Common Error Messages in Python
  • Covers many of the errors I have seen
• 16 Common Python Runtime Errors Beginners Find
  • This list puts the cause first, so you have to look a little harder if you are following the error message
• Intro to Python Debugging
  • Has some tips at the end, you probably know them but ICYMI

Never feel bad about bugs, no matter how many times you make them. We are only human and everyone makes mistakes. The important thing is to know how to identify and fix them.

During the paper

• Don't panic

May the force be ever in your posession

What to do, presented in pseudocode:

from dw_student import *
questions = []

for q_text in paper:
	q = read(q_text, carefully=True)
	if not q.isclear():
		request_clarification(q_text, questions)
	else:
		questions.append(q)

try:
	while True:
		for question in questions:
			if question.done:
				check(question)
				continue

			try:
				attempt(question)
				question.done = True
			except (TooDifficult, QuestionTimeout) as e:
				continue

except ExamOver:
	submit_tutor_code()

(To be honest, that's pretty generic and should work for any paper.)

Useful Resources

Note Some resources are still using Python 2. Take caution.

As I mentioned earlier, there are many guides out there for Python and programming in general. Here is a good subset:

• Programming Advice (py2)
  • Excellent advice for DW in general
• Python 2.7 Notes (py2)
  • A comprehensive collection of Python tips and tricks
  • You don't need to know all of it already, but it's handy as a reference
  • Some explanation of how the computer works behind the scenes (with cute cephalopods)
• Vivek's fork of the Guide
  • Some comments on return vs print
  • The original text on debugging, which I have modified to fit the "things to do" style of this guide
• PyFormat
  • String formatting is extremely useful, but its documentation is not the easiest thing to read
  • Many examples of how to use the various formats to achieve what you need
  • Remember the Calendar question? If you didn't already, try it with string formatting
• How to read the Python Documentation
  • Coming soon
• Boolean Practice (paywalled)
  • I will not reccomend the series, but feel free to look through it too (imagine if the profs taught this way)
  • Logic is beyond the realm of programming, but it seems like many problems need logic, so please be good at it

Remember to save them, as you will not be able to retrieve them during the paper.

---

Footnotes

¹ It will be hosted on Tutor, but do you really trust it to work if everyone uses it? ^
² Too often, I hear "huh, I didn't know this existed". ^
³ "Everything?!" Definitely, if given enough time. Unfortunately, I've never had that luxury. ^
⁴ Or on Tutor's server disks, if you had removed them from your own for some reason. ^
⁵ This sounds terrible, but it's the norm in practice -- why re-invent the wheel? ^
⁶ Very little about programming is actually writing code. ^
⁷ A common one is the Off-by-one error ^
⁸ Not every Exception is an Error (e.g. StopIteration), thus the name. ^