Skipped for now.

We trivially improved innerProduct (same asymptotic complexity before and after). Now we will see a real improvement. For simplicity I do a slightly simpler algorithm, prefix sums.

Algorithm partialSumsSlow Input: Positive integer n and a real array A of size n Output: A real array B of size n with B[i]=A[0]+…+A[i] for i ← 0 to n-1 do s ← 0 for j ← 0 to i do s ← s + A[j] B[i] ← s return B

The update of s is performed 1+2+…+n times. Hence the
running time is Ω(1+2+…+n)=&Omega(n^{2}).
In fact it is easy to see that the time is &Theta(n^{2}).

Algorithm partialSumsFast Input: Positive integer n and a real array A of size n Output: A real array B of size n with B[i]=A[0]+…+A[i] s ← 0 for i ← 0 to n-1 do s ← s + A[i] B[i] ← s return B

We just have a single loop and each statement inside is O(1), so the algorithm is O(n) (in fact Θ(n)).

**Homework:** Write partialSumsFastNoTemps, which is also
Θ(n) time but avoids the use of s (it still uses i so my name is not
great).

Often we have a data structure supporting a number of operations that will be applied many times. For some data structures, the worst-case running time of the operations may not give a good estimate of how long a sequence of operations will take.

If we divide the running time of the sequence by the number of
operations performed we get the average time for each operation in the
sequence,, which is called the **amortized running
time**.

Why amortized?

Because the cost of the occasional expensive application is
amortized over the numerous cheap application (I think).

**Example:**: (From the book.) The clearable table.
This is essentially an array. The table is initially empty (i.e., has
size zero). We want to support three operations.

- Add(e): Add a new entry to the table at the end (extending its size).
- Get(i): Return the ith entry in the table.
- Clear(): Remove all the entries by setting each entry to zero (for security) and setting the size to zero.

The obvious implementation is to use a large array A and an integer s indicating the current size of A. More precisely A is (always) of size N (large) and s indicates the extent of A that is currently in use.

We are ignoring a number of error cases.

We start with a size zero table and assume we perform n (legal) operations. Question: What is the worst-case running time for all n operations.

One possibility is that the sequence consists of n-1 add(e)
operations followed by one Clear(). The Clear() takes Θ(n),
which is the worst-case time for any operation (assuming n operations
in total). Since there are n operations and the worst-case is
Θ(n) for one of them, we might think that the worst-case
sequence would take Θ(n^{2}).

But this is wrong.

It is easy to see that Add(e) and Get(i) are Θ(n).

The **total** time for all the Clear() operations is
O(n) since in total O(n) entries were cleared (since at most n entries
were added).

Hence, the amortized time for each operation in the clearable ADT (abstract data type) is O(1), in fact Θ(1).

Overcharge for cheap operations and undercharge expensive so that the excess charged for the cheap (the profit) covers the undercharge (the loss). This is called in accounting an amortization schedule.

Assume the get(i) and add(e) really cost one ``cyber-dollar'', i.e., there is a constant K so that they each take fewer than K primitive operations and we let a ``cyber-dollar'' be K. Similarly, assume that clear() costs P cyber-dollars when the table has P elements in it.

We charge 2 cyber-dollars for every operation. So we have a profit of 1 on each add(e) and we see that the profit is enough to cover next clear() since if we clear P entries, we had P add(e)s.

All operations cost 2 cyber-dollars so n operations cost 2n. Since we have just seen that the real cost is no more than the cyber-dollars spent, the total cost is Θ(n) and the amortized cost is Θ(1).

Very similar to the accounting method. Instead of banking money, you increase the potential energy. I don't believe we will use this methods so we are skipping it.

Want to let the size of an array grow dynamically (i.e., during execution). The implementation is quite simple. Copy the old array into a new one twice the size. Specifically, on an array overflow instead of signaling an error perform the following steps (assume the array is A and the size is N)

- Allocate a new array B of size 2N
- For i←0 to N-1 do B[i]←A[i]
- Make A refer to B (this is A=B in C and java).
- Deallocate the old A (automatic in java; error prone in C)

The cost of this growing operation is Θ(N).

**Theorem**:
Given an extendable array A that is initially empty and of size N, the
amortized time to perform n add(e) operations is Θ(1).

**Proof**:
Assume one cyber dollar is enough for an add w/o the grow and that N
cyber-dollars are enough to grow from N to 2N.
Charge 2 cyber dollars for each add; so a profit of 1 for each add w/o
growing.
When you must do a grow, you had N adds so have N dollars banked.

Book is quite clear. I have little to add.

You might want to know

- Average running time.
- Compare two algorithms for speed.
- Determine the running time dependence of parameters of the algorithm.
- For algorithms that generate approximations, test how close they come to the correct value.

- Memory references (increasingly important--unofficial hardware comment).
- Comparisons (for sorting, searching, etc).
- Arithmetic ops (for numerical problems).