Day 18


For Next time

Appendix B Debrief

With two folks sitting around you, discuss the following questions:

  1. What are some of the challenges in comparing the efficiency of two algorithms?
  2. How does order of growth analysis address these challenges?
  3. In what situations might order of growth analysis be misleading (or at least tell an incomplete story)?
  4. Review your answers to Appendix B Problem 1 (from the reading journal). If there is confusion about one of the answers, take some time to discuss it at your table in more detail (or use the whiteboard). If any questions come up that you’d like to raise with the whole class, there will be some time to do so following your small group discussions.

Practice with Order of Growth

Suppose we are given two python functions do_procedure_f1 and do_procedure_f2. Each function processes a list L in some fashion (what these programs do is unimportant for this exercise). We are told that the order of growth of these procedures is:

What are the order of growths of the following computations?

def run_computation_1(L):

def run_computation_2(L):

def run_computation_3(L):
    for i in range(len(L)):

def run_computation_4(L):
    for i in range(len(L)):

def run_computation_5(L):
    if len(L) % 2 == 0:

def run_computation_6(L):
    if len(L) == 1:
        return 1

Order of Growth for Basic Python Operations

You have read Think Python Appendix B.1 and B.2. One of the most important takeaways is the listing of the order of growth for various operations on Python data structures. Here are some key points:

Empirical Analysis of Order of Growth

Next, you’ll be doing some exercises to empirically study order of growth of algorithms. Download the Jupyter notebook and run it on your machine.

A couple of things to keep in mind when interpreting the results graphically:

Project work time

A few things we’ve observed from several teams, along with some advice to keep in mind at this point in the project:

Project planning strategies

When undertaking a large project like this one, there are (>=) two schools of thought:

Top-down design

Starting with the big idea, continue to refine the plan and decompose things into smaller pieces with more and more detail until each is small enough to implement.

Bottom-up design

Work on small components of your project organically as needed, then compose them into a larger system at the end.

Each strategy has pros and cons - so which approach is right?

In this class as learners, we recommend that you take a bit of a middle path: do a bit of planning up front (but be willing to change course as you learn more), develop your code bottom up (but don’t forget to pop your head up every once in a while to make sure you’re still going in the right direction).

Final project “first draft”

We want you to finish today with three deliverables. These will form the core of your Architectural Review next time.

Non-zero amount of code written and committed

This is your “first draft”, and like all first drafts it will be edited later or thrown away entirely. It might look like an extremely minimal version of your main idea, with most functions/classes/etc replaced with stub versions with mock functionality. This is still valuable, since it gives you:

System architecture diagram

Again, first draft. We wouldn’t expect you to have every function and variable specified at this point, and this plan will change, but you should begin to develop a sense of what are the major components that will form your final system. One of the highest skills in software design is developing the ability to break a complex system into reasonable pieces that work together well.

Running list of questions

As you work, you will generate a long list of questions, unknowns, and things to research further as a team. You can select an appropriate subset of these to bring to the audience for your Architectural Review.