Q2.a:  Measure the runtime of L1 -- L2 when L1 = lists:seq(1, N), and
	 L2 = lists:reverse(L1).

  See time_sub/1 and time_sub/2 in hw1.erl.  Running time_sub/1 on
  thetis.ugrad.cs.ubc.ca, I got:
    N =   1000, T =   1.609e-3, T/N^2 =   1.609e-9
    N =   2000, T =   6.278e-3, T/N^2 =   1.569e-9
    N =   3000, T =   1.410e-2, T/N^2 =   1.567e-9
    N =   5000, T =   3.917e-2, T/N^2 =   1.567e-9
    N =  10000, T =   1.563e-1, T/N^2 =   1.563e-9
    N =  20000, T =   6.238e-1, T/N^2 =   1.559e-9
    N =  30000, T =   1.404e+0, T/N^2 =   1.560e-9
    N =  50000, T =   3.906e+0, T/N^2 =   1.562e-9

Q2.b:  Does the run-time appear to be linear, N log N, quadratic,
  exponential or something else.

  Time seems to be pretty close to quadratic in N as shown by the
  nearly constant ratio of T/N^2.

Q2.d:  I did quite a few experiments.  See the code time_subtract/2,
  and time_subtract/0.  Here's the data:
    L1 = [1, 2, ... N], L2 = lists:reverse(L1)
      N =   1000, T =   1.294e-4, T/(N*log2(N)) =   1.298e-8
      N =   2000, T =   2.293e-4, T/(N*log2(N)) =   1.045e-8
      N =   3000, T =   4.183e-4, T/(N*log2(N)) =   1.207e-8
      N =   5000, T =   5.235e-4, T/(N*log2(N)) =   8.521e-9
      N =  10000, T =   1.402e-3, T/(N*log2(N)) =   1.055e-8
      N =  20000, T =   2.376e-3, T/(N*log2(N)) =   8.315e-9
      N =  30000, T =   3.614e-3, T/(N*log2(N)) =   8.100e-9
      N =  50000, T =   6.503e-3, T/(N*log2(N)) =   8.332e-9

    L1 is a random list with elements selected from 1..100000, L2 = reverse(L1)
      N =   1000, T =   1.150e-3, T/(N*log2(N)) =   1.154e-7
      N =   2000, T =   7.614e-4, T/(N*log2(N)) =   3.472e-8
      N =   3000, T =   1.259e-3, T/(N*log2(N)) =   3.634e-8
      N =   5000, T =   2.297e-3, T/(N*log2(N)) =   3.739e-8
      N =  10000, T =   5.195e-3, T/(N*log2(N)) =   3.910e-8
      N =  20000, T =   1.207e-2, T/(N*log2(N)) =   4.225e-8
      N =  30000, T =   2.141e-2, T/(N*log2(N)) =   4.799e-8
      N =  50000, T =   3.573e-2, T/(N*log2(N)) =   4.577e-8

    L1 and L2 are random lists with elements selected from 1..N
      N =   1000, T =   5.289e-4, T/(N*log2(N)) =   5.307e-8
      N =   2000, T =   1.211e-3, T/(N*log2(N)) =   5.521e-8
      N =   3000, T =   1.844e-3, T/(N*log2(N)) =   5.321e-8
      N =   5000, T =   3.563e-3, T/(N*log2(N)) =   5.799e-8
      N =  10000, T =   8.486e-3, T/(N*log2(N)) =   6.386e-8
      N =  20000, T =   1.914e-2, T/(N*log2(N)) =   6.697e-8
      N =  30000, T =   3.222e-2, T/(N*log2(N)) =   7.221e-8
      N =  50000, T =   4.891e-2, T/(N*log2(N)) =   6.267e-8

    L1 and L2 are disjoint lists
      N =   1000, T =   7.483e-4, T/(N*log2(N)) =   7.509e-8
      N =   2000, T =   1.713e-3, T/(N*log2(N)) =   7.811e-8
      N =   3000, T =   3.128e-3, T/(N*log2(N)) =   9.026e-8
      N =   5000, T =   4.701e-3, T/(N*log2(N)) =   7.651e-8
      N =  10000, T =   1.030e-2, T/(N*log2(N)) =   7.749e-8
      N =  20000, T =   2.331e-2, T/(N*log2(N)) =   8.159e-8
      N =  30000, T =   3.889e-2, T/(N*log2(N)) =   8.716e-8
      N =  50000, T =   6.887e-2, T/(N*log2(N)) =   8.824e-8

  At first, I was really puzzled that the case where L1 = seq(1,N), and
  L2 = reverse(L1) ran so much faster than the others.  Eventually, I
  concluded that lists:sort/1 detects the case where the list is already
  sorted and just returns the list (or its reverse).  That motivated the
  second block of data where L1 is a random list, and L2 is its reverse.
  Now, I see times that are more like those of the other tests.

  Next, I noticed that when L2 = reverse(L1) (for random L1),
  the runtime appears to be roughly 40ns * N log2(N).  Note that this
  case eliminates all of the elements of L1.  When L1 and L2 are
  independent, random lists, with elements choses from 1..N, about
  half of the elements of L1 are eliminated, and the runtime appers
  to be roughly 60ns * N log2(N).  Finally, when L1 and L2 are
  disjoint, random lists, then the runtims is about 80ns * N log2(N).

  In all of these cases, the run-time grows as N log2(N).  There is
  a dependency on the size of the result list, because this determines
  how much work is done in the final sort and unzip operations of the
  algorithm.

  I'll add that I first ran my experiments on my laptop.  There was a
  fair amount of variation in the run-times (about a factor of two in
  the ratios that "should be roughly constant").  I suspected that this
  is due to the "TurboBoost" variable clock frequency stuff on my laptop's
  i5 processor.  I tried again on thetis.ugrad.cs.ubc.ca and got much
  more consistent results.  The results on my laptop were adequate
  (as, I expect, would be results on bowen.ugrad.cs.ubc.ca, or any other
  machine with a variable clock frequency).  The table are just clearer
  when running the code on thetis.