105 lines
3.2 KiB
Plaintext
105 lines
3.2 KiB
Plaintext
# Chapter 1
|
|
|
|
## Efficiency
|
|
|
|
Concerns:
|
|
1. Number of operations
|
|
2. Processor speeds
|
|
3. Storage space
|
|
|
|
## Interfaces
|
|
|
|
* Interface / abstract data type
|
|
|
|
### Queue interface
|
|
|
|
* `add(x)` (aka `queue`): add `x` to the queue
|
|
* `remove()` (aka `dequeue`): remove the next value from queue and return it
|
|
|
|
* Normal queue: the first element inserted is removed first
|
|
* Priority queue: elements are inserted with a priority, and the smallest
|
|
element is removed. This function is usually called `deleteMin`.
|
|
* LIFO queue: a stack; add and remove are called `push` and `pop`.
|
|
* Deque: generalisation of these
|
|
* `addFirst(x)`
|
|
* `removeFirst(x)`
|
|
* `addLast(x)`
|
|
* `removeLast(x)`
|
|
* Stack: addFirst, removeFirst
|
|
* Queue: addLast, removeFirst
|
|
|
|
### List interface
|
|
|
|
The List interface subsumes the Queue interface. A list is just a sequence of
|
|
values, and a Queue becomes a special case of it.
|
|
|
|
Interface:
|
|
|
|
* size()
|
|
* get(i): get i'th element
|
|
* set(i, x): set the i'th element to x
|
|
* add(i, x): insert x at position i
|
|
* remove(i): remove the i'th element
|
|
|
|
### USet (unordered sets)
|
|
|
|
USets are a collection of unique items in no particular order; this mimics a
|
|
mathematical set.
|
|
|
|
Interface:
|
|
|
|
* `size()`: returns the number of elements in the set
|
|
* `add(x)`: add x to the set if it doesn't already exist
|
|
* `remove(x)`: remove x from the set if it doesn't already exist
|
|
* `find(y)`: membership test
|
|
|
|
Note that y and x may be distinct objects, and only need to satisfy an
|
|
equality test. For example, a dictionary or hashmap is created using a tuple
|
|
`(key, value)`; `find` compares on `key` and two objects are considered equal
|
|
if their keys match.
|
|
|
|
### SSet (sorted set)
|
|
|
|
A USet where order matters. Its interface only changes in the `find` function:
|
|
|
|
* `find(x)`: find the smallest y s.t. y >= x. thereby returning a useful value
|
|
even if x isn't in the set. AKA successor search.
|
|
|
|
Difference between USet and SSet: sorting requires more steps (run time) and
|
|
complexity. A USet should be used unless an SSet is explicitly required.
|
|
|
|
## Mathematical background
|
|
|
|
(See notebook).
|
|
|
|
## The model of computation
|
|
|
|
Proper analysis requires a mathematical model of computation. The model in the
|
|
book is on a w-bit word-RAM model.
|
|
|
|
* we can access cells of memory, each of which stores a w-bit word
|
|
* basic operations (arithmetic and logical) take constant time
|
|
* cells can be read or written in constant time
|
|
* the memory manager allows allocating a block of k cells of memory in O(k)
|
|
time
|
|
* size constraint: w >= log(n) where n is the number of elements stored in a
|
|
data structure
|
|
* data structures use a generic type T such that T occupies one word
|
|
|
|
## Correctness, time complexity, and space complexity
|
|
|
|
Three factors for analysing a data structure:
|
|
|
|
* correctness: data structure must implement the interface
|
|
* time complexity: run times of operations on the data structure should
|
|
be as small as possible
|
|
* space complexity: the storage space used by a data structure should be
|
|
as small as possible
|
|
|
|
Run times come in three flavours:
|
|
|
|
1. Worst-case: an operation never takes longer than this
|
|
2. Amortized: if a data structure has an amortized run time of f(n), then
|
|
a sequence of m operations takes at most m f(n) time.
|
|
3. Expected: the actual run time is a random variable, and the expected
|
|
value of this run time is at most f(n). |