Linked Lists and Linked List Processing


Introduction:

This lecture reviews the basics of linked lists. You are expected to understand
how to draw linked lists (both full and abbreviated pictures), how to update
the drawings by hand simulating code that operates on linked lists (often 
iterating over linked lists; especially useful for debugging your linked list
code), how to add values at the front and rear of a linked list, how to search
for and remove a value from a linked list, and how to copy a linked list
efficiently.


Linked Lists:

We will start by looking at a simple class named LN, which we use to represent
List Nodes in a singly-linked list (with each object refering to another object
from that same class, or to null). This class declares two public instance
variables, instead of private ones with accessor/setter methods: note the
setters would allow any value to be stored there, so setters aren't of much
use (and would increase the syntactic complexity). It also declares one simple
constructor; a second one might have just an int i parameter and always set
next to null.

  public class LN {
    public LN (int i, LN n)
    {value = i; next = n;}

    public int value;  //Often generalized to a reference type
    public LN  next;
  }

Although not universally agreed upon, I think this style (public instance
variables) is easier to write code for, avoiding the extra syntax of doing
method calls to examine and set these instance variables. Also, we often 
declare classes like LN to be nested classes inside another class (in fact,
when doing so they are often declared static, and therefore are nested but not
inner classes), and therefore they can be manipulated only by the code in the
outer class which we also write.

We will examine an Object/Variable picture of a linked list built from this
class, and a simplified picture that represents all the necessary information,
but more compactly (if a bit more ambiguously). You should be able think in
terms of both the full and abbreviated pictures.  Given such pictures, we
should be able to understand how such data structures are accessed when using
combinations of .value and .next; e.g., in that data structure, what is the
value of x.next.next.value or x.next.next (this last value is a reference)?

Every occurence of "." means "follow the reference before the dot to the object
that it refers to." And every occurrence of an instance variable after the "."
 means "focus on the value inside the box for that instance variable" (which
might be a reference to follow later).

I have found that many students are just "faking" an understanding of how
linked structures are accessed and updated. They really don't understand the
material in the previous paragraph, or how code accesses and mutates linked
lists. They don't follow my recommendations to practice hand-simulating linked
list code, so they ultimately have a very hard time writing (and debugging)
their linked list code.



Iterating over Linked Lists:

We will examine the concept of "cursors" and how they unify the processing
of arrays (where cursors are ints) and linked lists (where cursors are
references): in each case a cursor (a small piece of data) tells "where we
are focussed" in a large data structure. With both we can use a standard "for"
loop for traversing the entire data structure (focusing on each piece of data
in the data structure, one after the other).

  for array x      : for (int i=0; i<x.length; i++     ) ...access x[i]
  for linked list x: for (LN  r=x; r!=null   ; r=r.next) ...access r.value

We will closely examine what r = r.next means, and more generally what it
means to copy any reference value into a variable.

  For the statement "r1 = r2;" the magic words are: "Make the box for the
  variable r1 refer to the same object that the box for the variable r2 refers
  to"

Note that if r2 stores null (refers to no object) then null should be stored in
r1 (so it should refer to no object).

While the semantics of reference assignment is not really complicated, many
students don't fully understand it, and such a misunderstanding makes it
difficult to write and debug code (by hand simulation) that uses linked lists.

Note that after r1 = r2; the test r1 == r2 evaluates to true: both variables
refer to the same object. So, of course r1.equals(r2) is also true, because
the state of the object r1 refers to is the same as the state of the object r2
referst to: because they refer to the same objects!

Today's first web reading shows and discussess code that 
  (1) sums up the values in a linked list
  (2) traverses linked lists to print their values (with commas between values)
  (3) finds the length of linked lists (the number of LN objects in a list)
  (4) counts how often a certain value occurs in a linked list, and 
  (5) checks whether a linked list is sorted (recall that empty lists and
      lists with one value are considered sorted).

All these operations are written with simple and similar list-processing code.

When we write code that process a linked list, we should be able to prove that 
every time that we write "r." then r is not null (i.e., that r refers to some
object). The typical continuation condition in a for loop that processes a
linked list (the test: r!=null) guarantees that the body of the loop can
contain "r." because the body is executed only if r is not null.

Likewise, if the body refers to "r.next." then we must ensure that r.next is
not null. If we ever execute "r." when r stores null, Java throws a
NullPointerException; although technically r is not a "pointer", it is a 
"reference", so this is a small abuse of terminology.

In this process we will discuss the "conditional expression" syntax in Java.

  (boolean expression ? ValueIfTrue : ValueIfFalse)

Conditional "expressions" are sometimes a shorter and simpler to understand
version of a conditional "statement": the if statement. Often a question arises
about which is "faster": I didn't know, but they probably run at about the same
speed. The benefit of a conditional expression derives from whether it
simplifies the code or not, compared to an "if statement" which is the typical
alternative. Not that expresions compute values; statements compute
state-changes.


Building Lists:

We will now write code to add a value to the front of a list and at the rear of
a list. In this way we can build any list we want, with the values in any
order.

Constrast this code with adding a new value at the front and rear of an array.
For a list, we can add a node at the front by changing one reference; for an
array we must first move every value in the array to the next higher index,
opening up index 0 in which we put the new value.

The code to add someValue at the front of LN x; is just

  x = new LN(someValue, x);

This code works whether x refers to an empty list (stores null) or whether x
stores a reference to a the first node in a list with any number of values.
Paraphrased, x now refers to a new node storing the value someValue, whose
.next refers to the list originally referred to by x. Draw some examples of
lists and hand simulate this code on them to ensure you completely understand
it. Yes, I really mean this. Serious, I really do mean it.

I still mean it. If you haven't done this do it now.

The opposite is true for adding at the rear of a data structure: for a list, we
must skip over every node starting from the front of the list to find the rear;
for an array we typically know the index of the last index and put the value
one beyond the end (increasing the array size if we need to) so we do not have
to examine the other values in the array: I'm assuming that the length of the
array is big enough to include another value at its end  without constructing
a new array with a larger length.

In fact, for adding a value at the rear of a linked list, we need two cases.
If the list is empty, we must store the new reference in x (in this case the
rear is the front too); if the list is not empty, we must store the new
reference in the .next instance variable of the node currently at the rear of
the list (the node whose .next stores null). This code is

  if (x == null)
    x = new LN (1,null);
  else {
    LN r = x;
    for (; r.next!=null; r=r.next)	or	while (r.next!=null)
      {}					  r = r.next;
    r.next = new LN(1,null);
  }

Notice two important things about the code in the else block

  1. We must declare r before/outside the for loop, because we use it
     after the for loop terminates (outside the loop). Variables declared
     inside a loop can be accessed only by code in the loop.

  2. We terminate the for loop when r refers to the LAST NODE in the linked
     list; the last node is the only one whose .next is null. In this case
     we DO NOT stop when r == null; that would mean r has gone to far: we
     have run off the list and lost the reference to the last node, which we
     were trying to use. We stop when r refers to the last node in the list,
     the node whose .next is null.

Today's first web reading shows how to put this code in a simple loop, to read
a sequence of values from a file and put them into a linked list that stores
all these values in the same order. This process requires the code to traverse
the entire linked list every time a new value is stored; mathematically, if we
read in 1,000 values we will have to scan approximately 500,000 nodes (that
number of values squared, divided by two: we skip 0 nodes to put in the first,
1 node to put in the second, 2 nodes to put in the third, and 999 nodes to put
in the 1000; so we skip 1 + 2 + ... + 999 nodes) which is slow. We can speed up
adding values via caching, discussed next.

We briefly discussed caching when we discussed the size method in the ArraySet
class. Caching is a classic "space for time" tradeoff: we use extra space to
store (and update) a precomputed value so that we don't have to recompute it.
In ArraySet, we stored the instance variable objectCount, so the size method
can just return this value; it doesn't have to count the number of values
stored in the Set each time we need to compute the size. Whenever we add or
remove a value from the set, we incremented/decremented this count.

Likewise, we often cache the length of a list implementing a data type (rather
than scanning the list to compute the length). If we need to repeatedly add a
value at the rear of a linked list, we can also cache a reference to the last
node in the linked list, so we can quickly add a new node at the rear (and then
the new node becomes the new end). With such a cached value we never have to
traverse the linked list to find its last node; we've already precomputed it.

Here is the code from the first web reading to accomplish this. As in the code
above, we still have two different cases, but neither case requires looping.

  LN lastCache = null;
  for (;;)
    try {
      int someValue = tbr.readInt();

      if (lastCache == null)
        lastCache = x = new LN (someValue,null);
      else {
        lastCache.next = new LN(someValue,null);
        lastCache      = lastCache.next;
      }

    } catch (EOFException eofe) {break;}

If the == null test is true, we put the new value in a node at the front and
initialize lastCache to this new node: it is at both the front and rear of the
linked list.

Notice that lastChache.next = ... extends the list by the new node (the new
node is now the only one in the list whose .next is null), and then
lastCache = .... updates that new node to be the end of the list. We could
accomplish these two action by the single statement

        lastCache = lastCache.next = new LN(someValue,null);

Finally, if we are inside a class that stores a linked list using the instance
variable "front", as well as a cache instance variable "rear", we can write the
following code in a method to insert at the rear.

    if (front == null)
      front = rear = new LN (someValue,null);
    else
      rear = rear.next = new LN(someValue,null);

We would store these two instance variables if we wanted to write a class
that implemented a queue, because values are added at the rear and removed
from the front.

Linked list processing isn't easy, so you should check the code you write by
doing small hand simulations of it, in a few different situations. We will 
spend some  time simulating the following code. It is not obvious what it does,
but we should be able to update the picture by executing this code (it
reverses, in place, the order of values in a list referred to by x).

  LN answer = null;
  for (;x!=null;) {
    LN toMove   = x;
    x           = x.next;
    toMove.next = answer;
    answer      = toMove; 
  }
    
  x = answer;


More Linked List Processing:

The second web reading shows a variety of code that processes linked lists. The
first section just repeats the code for adding a value at the front and rear
of a linked list.

The second section shows methods for searching unordered and ordered linked
lists. For an unordered linked list, we just use the standard for loop to
traverse it, and return a reference to the first node that contains the
searched-for value. Note that we use null just as we use -1 when returning
array indexes: it means the value was not found.

 public LN locate (int toLocate) {
    for (LN r=front; r!=null; r=r.next)
      if (r.value == toLocate)
         return r;

    return null;
  }

For an ordered list (assume an ordering of values smallest to largest) we can
stop as soon as we examine a value strictly greater than the one that we are
searching to find (or, of course, if we run out of nodes to examine). The
continuation condition in the resulting for loop is more complicated, but it
can terminate more quickly (without examining every value in the linked list,
unlike in the case of an unordered list).

  public LN locate (int toLocate)  {
    for (LN r=front; r!=null && r.value<=toLocate; r=r.next)
      if (r.value == toLocate)
         return r;

    return null;
  }

Notice that the continuation condition is that both (1) r != null, and
(2) r.value <= toLocation. Recall that && is a short-circuit boolean operator:
if the first condition is false, then the value of the entire boolean
expression is known to be false, so the second condition isn't even tested; if
it were tested, it would throw the NullPointerException because r.value makes
no sense when r is a null reference. Thus, the order in which the conditions
are tested is very important to the test working correctly.

The third section shows how to remove from a linked list the first node storing
a specified value. What is most interesting here is that when we remove a node,
we must change the .next instance variable in the node BEFORE the one that we 
are removing. In the picture in the web reading, we removed the node stroring
the value 7 by changing the .next in the node before the one with the value 7
(the one with the value 2), making the .next in the node storing the value 2
refer to the .next in the node storing the value 7, which refers to the node
storing the value 4. Thus, if we now follow the links, we visit nodes storing 5
then 2 then 4.

There are two basic approaches to solving this "node before" problem: the first
uses a single reference that checks values "one after" the node it refers to;
when it finds the one to remove, it changes the .next field in the node to
which it refers (which is one before the one to be removed). That code is

  public void removeFirst (int toRemove) {
    if (front == null)
      return;

    //if we execute the code below, we know front != null
    if (front.value == toRemove)
      front = front.next;
    else
      for (LN r=front; r.next!=null; r=r.next)
        if (r.next.value == toRemove) {
           r.next = r.next.next;
           return;
        }
  }

As with the code for adding at the front of a list, there is a special case for
(1) an empty list (front==null) and (2) for removing the first value in a
list. If front is null, we cannot even check front.value == toRemove.

Try hand simulating this code on a 5 node linked list, removing the first,
last, and some middle value. Especially interesting is the code

  r.next = r.next.next;

which says put into the next field in the node r refers to, whatever is in
the next field of the node coming after the one r refers to; this removes
the node after the one r refers to from the list.

The second approach to solving this "node before" problem is to use two
variables: one to traverse through the nodes in the list looking for the value
to remove, and a second variable that remember where the first one "just was"
(sometimes called a ghost reference). It is the .next field in the node
referred to by this second (ghost) variable that is changed.

  public void removeFirst (int toRemove) {
    for (LN prev=null,r=front; r!=null; prev=r,r=r.next)
      if (r.value == toRemove) {
        if (prev == null)
           front = front.next;  //could use front = r.next too
        else
           prev.next = r.next;
        return;
      }
  
Notice the initialization and update part of the for (...) initializes/updates
two references, not just one. The variable prev always refers to the node one
before the variable r refers to (and the special value null when r refers to
the first node on the list).

That section also shows code to remove all nodes that contain a certain value.
See "header" and "trailer" lists in the Special Linked List lecture (the next
one) for a easier way to accomplish this task.

The fourth section shows that determining whether two lists are equal requires
traversing both lists simultaneously, looking for any different values. If
there are different values or one list is shorter than the other, this method
will return false.

It also shows two ways to copy a list: (1) by building up a copy in the reverse
order (by always adding values from the original list to the front of the new
list) and then reversing the list. (2) by caching the rear of the list, and
adding values from the original list to the rear.

See this section for the code.

The last list-processing section shows an in-place reverse method, and a
"cheap" way to sort lists: by putting the list values into an array, sorting
the array, and then putting the sorted array values back into the linked list.

We will study sorting in more depth later in the quarter, and see fast methods
that sort arrays and lists. When we discuss complexity classes for algorithms,
we will say that copying the information into/out of the array doesn't change
the complexity class of sorting.