Class 29: Lists, Concluded

Held Monday, March 15

Summary

• Other issues
• Assignment 7 (Sorting) due.

Contents

Handouts

• Notes on assignment 6.
• Notes on assignment 7.

Notes

• I've graded assignment 6.
  • An answer key is available.
  • We'll discuss some issues in class, but I expect you to read over the answer key.
  • Yes, some folks earned A's.
  • 1/3 is 0, as is 2/3. You should know this.
• assignment 7 is due.
  • I understand a number of you looked at the answer key (which I made available a little bit early) before completing the assignment. That's a big no-no. Even worse, some of you just copied the answer key. You were expected to develop your own working and tested code.
  • I had not planned to grade the assignment. Experience shows that you learn a lot about sorting routines by trying to implement them, but gain very little by having someone pick apart your code. However, I would like to give those of you who worked hard on it the opportunity to gain explicitly as well as implicitly from your work. Hence, I will treat this as an extra credit assignment for those of you who ask me to.
  • An answer key is available.
• I've gone through my stack of stuff, and believe that I've graded all the homeworks you've turned in. Let me know if you think you haven't gotten something graded.
• Friday's class is optional (in case you want to leave early for Spring break). We'll probably do a sort laboratory on animation.
• Please read lab O1: Object-Oriented Design for tomorrow's class.
• Are there questions on exam 2? (I've now prepared an answer key, and can speak relatively coherently on the various problems.)
• This appears to be yet another outline that I've gone slightly overboard on.

Static Methods, Revisited

• There were some problems with static methods in assignment 7. That's in part because I was attempting to translate code designed for one context to another (and wasn't completely successful).
• As you (hopefully) learned early in the semester, there are two ``kinds'' of methods: object methods and static methods.
  • Object methods are attached to objects. You must create an object to use them.
  • Static methods do not require objects. You can call them by using the class name. (You need the keyword static when declaring static methods.)
• As you know from experience, object methods can access the fields of an object and can call other object methods.
• Static methods, on the other hand, cannot directly access fields or other object methods (after all, there's no object to supply those fields or methods).

Testing Sorting Methods

• I'd like to know how you tested your sorting routines.
• We'll discuss a number of options for sorting.
• Eventually, you should look at the examples I've come up with in the notes on assignment 7.

Implementing Lists with Nodes

• Rather than building the array all at once, we could build each ``cell'', one at a time, linking each cell to the next cell. Such structures are typically called nodes (or cons cells in Scheme).
• Each cell contains a value and a reference to the next cell.
• As a Java class,

  /**
   * Nodes for a singly-linked list.
   *
   * @author Samuel A. Rebelsky
   * @version 1.1 of March 1999
   */
  public class Node {
    /** 
     * The value in the current node.  A value of null 
     * indicates (...)
     */
    protected Object value;
    /** 
     * The next node in the list.  A value of null
     * indicates that this is the last element of the list.
     */
    protected Node next;
    ...
  } // Node
  

• We use a special value, null, for links from nodes that have no next element.
  • Alternatively, you can think of null as representing ``not a node'' or ``nil'' or ``empty''.

A Wrapper Class

• We then wrap our nodes in a separate list class. Why? So that it's easier to handle issues like insertion and removal.
  • However, this can make it harder to write methods like tail, which now needs to create new list objects.
  • Scheme lists do not have this separate wrapper class for just this reason.
• If you're using a wrapper class, you can also include a number of other fields, such as a link to the current element of the list and a link to the end of the list.
• For our purposes, we can assume the following definition

  /**
   * A singly-linked list.
   *
   * @author Samuel A. Rebelsky
   * @version 1.0 of March 1999
   */
  public class LinkedOrderedList 
    implements OrderedList 
  {
    /** The elements of the list, starting at the front */
    protected Node front;
    /** The last element of the list. */
    protected Node back;
    /** The current element of the list. */
    protected Node current;
    ...
  } // LinkedOrderedList
  

Insertion in Linked Lists

• One primitive operation on lists is insertion.
• As discussed earlier, there are a number of forms of insertion in a list, including
  • Insertion of a new element at the head
  • Insertion of a new element at the tail
  • Insertion of a new element before/after the current position
• If we are using the LinkedOrderedList class, we might write our insert at head function as follows

    /** 
     * Insert a non-null object at the head of the list. 
     * pre: The element is not null.
     * pre: The current list has been initialized
     * post: The head of the list is now that element.
     * post: The tail of the list is the previous list.
     */
    public void insertAtHead(Object element) {
      // Create a node to hold the new element.
      Node new_head = new Node(element,null);
      // Is the list currently empty?  If so, just insert the element
      // at front and back, and we're done.
      if (front == null) {
        front = new_head;
        back = new_head;
        current = new_head;
      }
      // Otherwise, update the next reference of the new head
      // and replace the front of the list
      else {
        new_head.setNext(front);
        front = new_head;
        // We don't need to modify the back of the list.
        // Should we modify current?
      }
    } // insertAtHead(Object)
  

• Insertion at the end of the list (i.e., appending to a list) also depends on which representation of list you choose, and whether or not there is a back field.
• In the simplest Node-based version (in which we do have a back.

    /**
     * Append an element to the end of the list.
     * pre: The element is not null.
     * pre: The list has been appropriately initialized and maintained.
     * post: The list now contains the element at the end.
     */
    public void appendToEnd(Object element) {
      // Create the node for the new element
      Node new_end = new Node(element,null);
      // Special case: the list is empty
      if (front == null) {
        front = new_end;
        back = new_end;
        current = new_end;
      }
      // Normal case: we just need to update the end
      else {
        back.setNext(new_end);
        back = new_end;
      }
    } // appendToEnd(Object)
  

• We can make this more complicated by dropping the back field. How to do so is left as an exercise for the reader.

History

• Created Monday, January 11, 1999.
• Added short summary on Friday, January 22, 1999.
• Filled in some details on Sunday, March 14, 1999. The discussion of linked lists was taken from the previous outline (and parts were therefore taken from last year's outlines).
• Added a few notes on Monday, March 15, 1999. Removed discussion of doubly linked lists after class (now a handout).