- Can we do better?
- Move-to-the front lists.
- Indirection, the programmer's friend.
- Move to the front lists require O(n) data movement.
- Which is doubly expensive.
- Can we do better?
- What's the problem?
-
data[i + 1]
is cheap to use but expensive to maintain.
- It requires a lot of shifting around.
- Can we maintain the next-element relation without so much shifting
around?
- Array-based linked lists.
- Remember what arrays are: they map indices to values.
- And indicies are integers, which are cheap to move.
- If mapping is good once, maybe it'll be good twice.
- Given element
i
, find the next element at location next[i]
.
-
next[i]
is almost as cheap as i + 1
.
- Maintaining
next
costs something, but not as much as moving
data elements around.
- And it's more complex to implement.
- Move-to-the-front lists work best when the data are skewed.
- The skew may change over time.
- An example of a self-adjusting data structure.
- An alternative is to move forward one on each access.
- Performance can degenerate due to Alphonse and Gastoning.
- Implementation.
- Data structures.
- An array for elements.
- An array for next indices.
- A count of the number of elements in the roster.
- The index of the roster's first element (it's head).
- The index of the free list.
- Procedures
- Initialization.
- Hang everything on the free list
-
add(e)
- Allocate an element from the free list.
- Link the new element at the head of the list.
-
find(e)
- Walk the elements one by one, checking the data against
e
.
-
delete(e)
- Find
e
.
- Splice it out of the list.
- This is most easily done with a trailing index.
- And tailing indices are most easly done with a dummy head.
- Hang the element on the free list.
This page last modified on 13 October 2003.