CSC153 2004S, Class 47: Linear Structures

Admin:
* Homework 7 ready!
* Prospies!
  * What is your name?
  * Where are you from?
  * Where else are you considering?
  * Reflect actively on the claim that "Respect between students and professors must be a two-way street."
  * Nick from a small school in Charlestown South Carolina; We're stuck with him already; "Sounds about right"
  * Nico from Austin vs. UT Austin (more CS majors than Grinnell has students), "If it were a one-way street, which way would it go?" (South)
  * Adam from an attic in Wellesley; Dartmouth and Swarthmore; Respect is not necessary, but enjoyable
  * Anthony from Virginia; Rochester, Rose-Hullman, Colorado School of Mines; "I refuse to answer that question without the time to sufficiently research the issue."
* Cool convo next week
* Next week is also Whitman week
* Question: How do you get to the eboard?

Overview:
* Linear structures: Simple collections
  * Key design principle
  * Basic operations
  * Additional operations
* Stacks
* Queues
* Priority Queues

Goal in designing types: Simplicity
* Choose as few operations as possible
* Make those operations as generic as possible
* Add meaning and operations in subclasses/subtypes/subinterface
* Sometimes we look for a simplified superclass

Linear Structures
* Idea: Sometimes we have large amounts of information and we only care about two basic things:
  * Add something
  * Get something
* What we get (the "get policy") depends on the particular kind of collection we have
* What methods should all linear structures provide?
  * void add(Object something)
  * Object get()
* What preconditions would you make
  * get() has a precondition that there are things in the collection
  * isEmpty() might be a valuable method
  * add(): The stack can't be full; The data type must be correct
  * isFull() might be a valuable method
    * At some point every structure will fill
    * There's some good evidence of this:
      * Microsoft: Viruses, whee!
      * Mars lander: 
* Are there other useful methods?
  * long size()
  * long howMuchSpaceIsAvailable()
      throws UnimplementedException
  * Object[] dump()
  * Object clone()
  * Object[] dump(int howMany)
  * String toString() "That would be great"
  * Object peek(): Find out what get() would return without removing it
    * And replace get() by remove().  Power!  No.
* Are there some suspicious methods?
    * Could be difficult to implement
    * Could be fun to implement
  * nod()
  * sort(Order o): Reorder the stuff
    * Dangerous because it may violate one of the principles by which we've designed the data struct

* Further detour: Why early rockets crashed
  DO I = 1,20 ...
  DO I = 1.20 ...

Specializations:
* FIFO (first in first out) principle: You get things in the order that they are added (if I add A before B, I get A before B): Queues (sometimes Pipes)
* LIFO (last in first out) principle: You get things in the reverse order that they are added (if I add A before B, I get B before A): Stacks
  * It's how procedure calls are implemented in most programming langauges
  * It makes sense for some sets of data (e.g., grading homework)
  * 
* Priority principle: The most important thing is removed next
  * Associate a number/word/color that indicates priority
  * Use an Order to determine the priority
* Saul would like to implement priority queues with a dynamic sorted array of queues

Queues: Linear Structures with FIFO principles
* put: enqueue
* get: dequeue
* peek: peek

Dequeues: Doubly-ended queues
* Add at front or end
* Remove from front or end
* Not really linear structures

Stacks: Linear structures with LIFO principles
* put: push
* get: pop
* peek: peek

One of your goals in implementing these structues is efficiency: As close to constant time as you can get them

If you implement priority queues well, you get a nice, simple sorting method
* Add everything to the priority queues O(n*cost of add)
* Remove everything (in order): O(n*cost of get)