ADT Sorted List. Goals

Transcription

1 41582_CH04_DALECPP.qxd 9/22/06 11:04 AM Page 191 ADT Sorted List After studying this chapter, you should be able to Describe the Abstract Data Type Sorted List from three perspectives Implement the following Sorted List operations using an array-based implementation Create and destroy a list Determine whether the list is full Insert an element Retrieve an element Delete an element Create an array in dynamically allocated storage Goals Implement the list operations outlined above using a linked implementation Implement the binary search algorithm Compare the two implementations of the ADT Sorted List in terms of Big-O approximations Compare the implementations of the Unsorted List ADT and the Sorted List ADT in terms of Big-O Analysis Distinguish between bounded and unbounded ADTs at the logical and implementation levels Identify and apply the phases of the object-oriented methodology

2 41582_CH04_DALECPP.qxd 9/22/06 11:04 AM Page Chapter 4: ADT Sorted List 4.1 Abstract Data Type Sorted List In the last chapter, we said that a list is a linear sequence of items; from any item (except the last) you can access the next one. We looked at the specifications and implementation for the operations that manipulate a list and guarantee this property. In this chapter, we add an additional property: The key member of any item (except the first) comes before the key member of the next one. We call a list with this property a sorted list. Logical Level When we defined the specifications for the Unsorted List ADT, we commented that there was nothing in the specifications to prevent the list from being stored and maintained in sorted order. Now, we have to change the specifications to guarantee that the list is sorted. We must add preconditions to those operations for which order is relevant. The observer functions do not change the state of the list, so we do not have to change them. The algorithm for RetrieveItem can be improved but still works on a sorted list. The algorithms for ResetList and GetNextItem are not changed by the additional property. What then must be changed? InsertItem and DeleteItem. Notice that these comments apply to the ADT at the logical level, so are in handwriting font. The changed specifications are shaded. Sorted List ADT Specification Structure: The list elements are of ItemType. The list has a special property called the current position the position of the last element accessed by GetNextItem during an iteration through the list. Only ResetList and GetNextItem affect the current position. Definitions (provided by user in class ItemType): MAX_ITEMS: A constant specifying the maximum number of items in the list RelationType: An enumeration type that consists of LESS, GREATER, EQUAL Member function of ItemType that must be included: RelationType ComparedTo(ItemType item) Function: Determines the ordering of two ItemType objects based on their keys. Precondition: Self and item have their key members initialized.

3 41582_CH04_DALECPP.qxd 9/22/06 11:04 AM Page Abstract Data Type Sorted List 193 Postcondition: Function value = LESS if the key of self is less than the key of item. = GREATER if the key of self is greater than the key of item. = EQUAL if the keys are equal. Operations (provided by Sorted List ADT) MakeEmpty Function: Initializes list to empty state. Preconditions: None Postcondition: List is empty. Boolean IsFull Function: Precondition: Postcondition: int GetLength Function: Precondition: Postcondition: Determines whether list is full. List has been initialized. Function value = (list is full) Determines the number of elements in list. List has been initialized. Function value = number of elements in list RetrieveItem (ItemType& item, Boolean& found) Function: Retrieves list element whose key matches item s key (if present). Preconditions: List has been initialized. Key member of item is initialized. Postconditions: If there is an element someitem whose key matches item s key, then found = true and item is a copy of someitem; otherwise found = false and item is unchanged. List is unchanged. InsertItem (ItemType item ) Function: Adds item to list. Preconditions: List has been initialized. List is not full. item is not in list. List is sorted by key member using function ComparedTo. Postconditions: item is in list. List is still sorted.

4 41582_CH04_DALECPP.qxd 9/22/06 11:04 AM Page Chapter 4: ADT Sorted List DeleteItem (ItemType item ) Function: Deletes the element whose key matches item s key. Preconditions: List has been initialized. Key member of item is initialized. List is sorted by key member using function ComparedTo. One and only one element in list has a key matching item s key. Postconditions: No element in list has key matching item s key. List is still sorted. ResetList Function: Precondition: Postcondition: Initializes current position for an iteration through the list. List has been initialized. Current position is prior to list. GetNextItem (ItemType& item ) Function: Gets the next element in list. Preconditions: List has been initialized. Current position is defined. Element at current position is not last in list. Postconditions: Current position is updated to next position. item is a copy of element at current position. Application Level The application level for the Sorted List ADT is the same as that for the Unsorted List ADT. As far as the user is concerned, the interfaces are the same. The only difference is that when GetNextItem is called in the Sorted List ADT, the element returned is the next one in order by key. If the user wants that property, the client code includes the file containing the class SortedType rather than UnsortedType. Implementation Level InsertItem Function To add an element to a sorted list, we must first find the place where the new element belongs, which depends on the value of its key. Let s use an example to illustrate the insertion operation. Suppose that Becca has made the honor roll. To add the element Becca to the sorted list pictured in Figure 4.1(a) while maintaining the alphabetic ordering, we must accomplish three tasks: 1. Find the place where the new element belongs. 2. Create space for the new element. 3. Put the new element in the list.

5 41582_CH04_DALECPP.qxd 9/22/06 11:04 AM Page Abstract Data Type Sorted List 195 (a) Original list (b) Insert Becca length info [0] Anne [1] Bobby [2] Chris [3] Sarah 4 length info [0] Anne [1] Bobby [2] Chris [3] Sarah 4 moretosearch: false location : 1 logical garbage logical garbage [MAX_ITEMS 1] [MAX_ITEMS 1] (c) Result length info [0] Anne [1] Becca [2] Bobby [3] Chris [4] Sarah 5 moved down logical garbage [MAX_ITEMS 1] Figure 4.1 Inserting into a sorted list

6 41582_CH04_DALECPP.qxd 9/22/06 11:04 AM Page Chapter 4: ADT Sorted List The first task involves traversing the list and comparing the new item to each item in the list until we find an item where the new item is less (in this case, Becca). We set more- ToSearch to false when we reach a point where item.comparedto(info(location)) is LESS. At this point, location indicates where the new item should go (see Figure 4.1b). If we don t find a place where item.comparedto(info(location)) is LESS, then the item should be put at the end of the list. In this case, location equals length. Now that we know where the element belongs, we need to create space for it. Because the list is sorted, Becca must be put into the list at Info(location). Of course, this position may already be occupied. To create space for the new element, we must move down all list elements that follow it, from location through length 1. Then, we just assign item to Info(location) and increment length. Figure 4.1(c) shows the resulting list. Let s summarize these observations in algorithm form before we write the code: InsertItem Initialize location to position of first item Set moretosearch to (have not examined Info(last)) while moretosearch switch (item.comparedto(info(location))) case LESS : Set moretosearch to false case EQUAL : // Cannot happen because item is not in list. case GREATER : Set location to Next(location) Set moretosearch to (have not examined Info(last)) for index going from length DOWNTO location + 1 Set Info(index ) to Info(index 1) Set Info(location) to item Increment length Recall that the preconditions on InsertItem state that the item is not already present in the list, so we do not need to have EQUAL as a label in the switch statement. Translating the list notation into the array-based implementation gives us the following function: void SortedType::InsertItem(ItemType item) bool moretosearch; int location = 0; moretosearch = (location < length);

7 41582_CH04_DALECPP.qxd 9/22/06 11:04 AM Page Abstract Data Type Sorted List 197 while (moretosearch) switch (item.comparedto(info[location])) case LESS : moretosearch = false; break; case GREATER : location++; moretosearch = (location < length); break; for (int index = length; index > location; index--) info[index] = info[index 1]; info[location] = item; length++; Does this function work if the new element belongs at the beginning or the end of the list? Draw a picture to confirm for yourself how the function works in each case. DeleteItem Function When discussing the function DeleteItem for the Unsorted List ADT, we commented that if the list was sorted, we would have to move the elements up one position to cover the one being removed. Moving the elements up one position is the mirror image of moving the elements down one position. The loop control for finding the item to delete is the same as for the unsorted version. Initialize location to position of first item Set found to false while NOT found switch (item.comparedto(info(location))) case GREATER : Set location to Next(location) case LESS : // Cannot happen because list is sorted. case EQUAL : Set found to true for index going from location + 1 TO length 1 Set Info(index 1) to Info(index) Decrement length Examine this algorithm carefully and convince yourself that it is correct. Try cases where you are deleting the first item and the last one.

8 41582_CH04_DALECPP.qxd 9/22/06 11:04 AM Page Chapter 4: ADT Sorted List void SortedType::DeleteItem(ItemType item) int location = 0; while (item.comparedto(info[location])!= EQUAL) location++; for (int index = location + 1; index < length; index++) info[index 1] = info[index]; length--; Improving the RetrieveItem Function If the list is not sorted, the only way to search for a value is to start at the beginning and look at each item in the list, comparing the key member of the item for which we are searching to the key member of each item in the list in turn. We used this algorithm in the RetrieveItem operation in the Unsorted List ADT. If the list is sorted by key value, there are two ways to improve the searching algorithm. The first way is to stop when we pass the place where the item would be found if it were present. Look at Figure 4.2(a). If you are searching for Chris, a comparison with Judy would show that Chris is LESS. Thus you have passed the place where Chris would be found if it were present. At this point you can stop and return found as false. Fig- (a) Retrieve Chris (b) Retrieve Susy length info [0] [1] [2] [3] Bobby Judy June Sarah 4 moretosearch: true found : false location : 1 length info [0] [1] [2] [3] Bobby Judy June Sarah 4 moretosearch: false found : false location : 4 logical garbage logical garbage [MAX_ITEMS 1] [MAX_ITEMS 1] Figure 4.2 Retrieving in a sorted list

9 41582_CH04_DALECPP.qxd 9/22/06 11:04 AM Page Abstract Data Type Sorted List 199 ure 4.2(b) shows what happens when you are searching for Susy: location is equal to 4, moretosearch is false, and found is false. If the item we are seeking appears in the list, the search is the same for both the unsorted list and the sorted list. When the item is not there, however, the new algorithm is better. We do not have to search all of the items to confirm that the one we want is not present. When the list is sorted, however, we can improve the algorithm even more. Binary Search Algorithm Think of how you might go about finding a name in a phone book, and you can get an idea of a faster way to search. Let s look for the name David. We open the phone book to the middle and see that the names there begin with M. M is larger than D, so we search the first half of the phone book, the section that contains A to M. We turn to the middle of the first half and see that the names there begin with G. G is larger than D, so we search the first half of this section, from A to G. We turn to the middle page of this section, and find that the names there begin with C. C is smaller than D, so we search the second half of this section that is, from D to G and so on, until we reach the single page that contains David. Figure 4.3 illustrates this algorithm. PHONE BOOK A Z L M (A M) G G (A G) C C D D David (A C) Figure 4.3 (D G) A binary search of the phone book

10 41582_CH04_DALECPP.qxd 9/22/06 11:04 AM Page Chapter 4: ADT Sorted List We begin our search with the whole list to examine; that is, our current search area goes from info[0] through info[length 1]. In each iteration, we split the current search area in half at the midpoint; if the item is not found there, we search the appropriate half. The part of the list being searched at any time is the current search area. For instance, in the first iteration of the loop, if a comparison shows that the item comes before the element at the midpoint, the new current search area goes from index 0 through the midpoint 1. If the item comes after the element at the midpoint, the new current search area goes from the midpoint + 1 through index length 1. Either way, the current search area has been split in half. We can keep track of the boundaries of the current search area with a pair of indexes, first and last. In each iteration of the loop, if an element with the same key as item is not found, one of these indexes is reset to shrink the size of the current search area. How do we know when to quit searching? Two terminating conditions are possible: item is not in the list and item has been found. The first terminating condition occurs when there s no more to search in the current search area. The second terminating condition occurs when item has been found. Set first to 0 Set last to length 1 Set found to false Set moretosearch to (first <= last) while moretosearch AND NOT found Set midpoint to (first + last) / 2 switch (item.comparedto(info[midpoint])) case LESS : Set last to midpoint 1 Set moretosearch to (first <= last) case GREATER : Set first to midpoint + 1 Set moretosearch to (first <= last) case EQUAL : Set found to true Notice that when we look in the lower half or upper half of the search area, we can ignore the midpoint because we know it is not there. Therefore, last is set to midpoint 1, or first is set to midpoint + 1. The coded version of our algorithm follows: void SortedType::RetrieveItem(ItemType& item, bool& found) int midpoint; int first = 0; int last = length 1; bool moretosearch = first <= last; found = false;

11 41582_CH04_DALECPP.qxd 9/22/06 11:04 AM Page Abstract Data Type Sorted List 201 while (moretosearch &&!found) midpoint = (first + last) / 2; switch (item.comparedto(info[midpoint])) case LESS : last = midpoint 1; moretosearch = first <= last; break; case GREATER : first = midpoint + 1; moretosearch = first <= last; break; case EQUAL : found = true; item = info[midpoint]; break; Let s do a walk-through of the binary search algorithm. We are searching for the item bat. Figure 4.4(a) shows the values of first, last, and midpoint during the first iteration. In this iteration, bat is compared with dog, the value in info[midpoint]. Because bat is less than (comes before) dog, last becomes midpoint 1 and first stays the same. Figure 4.4(b) shows the situation during the second iteration. This time, bat is [0] ant first [0] ant first [0] ant first and midpoint [0] ant [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] cat chicken cow deer dog fish goat horse rat snake midpoint last [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] cat chicken cow deer dog fish goat horse rat snake midpoint last bat cannot be in this part of the list [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] cat chicken cow deer dog fish goat horse rat snake last bat cannot be in this part of the list [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] cat chicken cow deer dog fish goat horse rat snake bat first, last, and midpoint cannot be in this part of the list First iteration bat < dog Second iteration bat < chicken Third iteration bat > ant Fourth iteration bat < cat (a) (b) (c) (d) Figure 4.4 Trace of the binary search algorithm

12 41582_CH04_DALECPP.qxd 9/22/06 11:04 AM Page Chapter 4: ADT Sorted List Table 4.1 compared with chicken, the value in info[midpoint]. Because bat is less than (comes before) chicken, last becomes midpoint 1 and first again stays the same. In the third iteration (Figure 4.4c), midpoint and first are both 0. The item bat is compared with ant, the item in info[midpoint]. Because bat is greater than (comes after) ant, first becomes midpoint + 1. In the fourth iteration (Figure 4.4d), first, last, and midpoint are all the same. Again, bat is compared with the item in info[middle]. Because bat is less than cat, last becomes midpoint 1. Now that last is less than first, the process stops; found is false. The binary search is the most complex algorithm that we have examined so far. Table 4.1 shows first, last, midpoint, and info[midpoint] for searches of the items fish, snake, and zebra, using the same data as in the previous example. Examine the results in Table 4.1 carefully. Iteration Trace of the Binary Search Algorithm Terminating Iteration first last midpoint info[midpoint] Condition item: fish First dog Second horse Third fish found is true item: snake First dog Second horse Third rat Fourth snake found is true item: zebra First dog Second horse Third rat Fourth snake Fifth last < first Notice that the loop never executes more than four times. It never executes more than four times in a list of 11 components because the list is cut in half each time through the loop. Table 4.2 compares a linear search and a binary search in terms of the average number of iterations needed to find an item. If the binary search is so much faster, why not use it all the time? It is certainly faster in terms of the number of times through the loop, but more computations are executed within the binary search loop than in the other search algorithms. If the number of components in the list is small (say, less than 20), the linear search algorithms are faster because they perform less work at each iteration. As the number of components in the list increases, however, the binary search algorithm becomes relatively more efficient. Always remember that the binary search requires the list to be sorted and sorting takes time. Here are the specification and implementation files for class SortedType with reduced documentation.

13 41582_CH04_DALECPP.qxd 9/22/06 11:04 AM Page Abstract Data Type Sorted List 203 Table 4.2 Comparison of Linear and Binary Search Average Number of Iterations Length Linear Search Binary Search , , #include "ItemType.h" // File ItemType.h must be provided by the user of this class. // ItemType.h must contain the following definitions: // MAX_ITEMS: the maximum number of items on the list // ItemType: the definition of the objects on the list // RelationType: LESS, GREATER, EQUAL // Member function ComparedTo(ItemType item) which returns // LESS, if self "comes before" item // GREATER, if self "comes after" item // EQUAL, if self and item are the same class SortedType public: SortedType(); void MakeEmtpy(); bool IsFull() const; int GetLength() const; void RetrieveItem(ItemType& item, bool& found); void InsertItem(ItemType item); void DeleteItem(ItemType item); void ResetList(); void GetNextItem(ItemType& item); private: int length; ItemType info[max_items]; int currentpos; ; // Implementation file for sorted.h #include "sorted.h" SortedType::SortedType()

14 41582_CH04_DALECPP.qxd 9/22/06 11:04 AM Page Chapter 4: ADT Sorted List length = 0; void SortedType::MakeEmpty() length = 0; bool SortedType::IsFull() const return (length == MAX_ITEMS); int SortedType::GetLength() const return length; void SortedType::RetrieveItem(ItemType& item, bool& found) // Binary search algorithm is used. int midpoint; int first = 0; int last = length - 1; bool moretosearch = first <= last; found = false; while (moretosearch &&!found) midpoint = ( first + last) / 2; switch (item.comparedto(info[midpoint])) case LESS : last = midpoint - 1; moretosearch = first <= last; break; case GREATER : first = midpoint + 1; moretosearch = first <= last; break; case EQUAL : found = true; item = info[midpoint]; break; void SortedType::DeleteItem(ItemType item) int location = 0;

15 41582_CH04_DALECPP.qxd 9/22/06 11:04 AM Page Abstract Data Type Sorted List 205 while (item.comparedto(info[location])!= EQUAL) location++; for (int index = location + 1; index < length; index++) info[index - 1] = info[index]; length--; void SortedType::InsertItem(ItemType item) bool moretosearch; int location = 0; moretosearch = (location < length); while (moretosearch) switch (item.comparedto(info[location])) case LESS : moretosearch = false; break; case GREATER : location++; moretosearch = (location < length); break; for (int index = length; index > location; index--) info[index] = info[index - 1]; info[location] = item; length++; void SortedType::ResetList() // Post: currentpos has been initialized. currentpos = -1; void SortedType::GetNextItem(ItemType& item) // Post: item is current item. // Current position has been updated. currentpos++; item = info[currentpos]; Test Plan We can use the same test plan that we employed with the unsorted list with the expected outputs changed to reflect the ordering. We need to modify the items to be deleted to reflect where the items fall in the list; that is, we need to delete one from each end as well as from in the middle.

16 41582_CH04_DALECPP.qxd 9/22/06 11:04 AM Page Chapter 4: ADT Sorted List Operation to Be Tested and Description of Action Input Values Expected Output Constructor print getlength 0 InsertItem Insert four items and print 5, 7, 6, Insert item and print RetrieveItem Retrieve 4 and print whether found Retrieve 1 and print whether found Retrieve 9 and print whether found Retrieve 10 and print whether found IsFull Invoke (list is full) Delete 5 and invoke Item is not found Item is found Item is found Item is not found List is full List is not full DeleteItem Delete 1 and print Delete 6 and print 7 9 Delete 9 and print 7 File SlistType.in contains the input to listdr.cpp (the test driver) that reflects this test plan; SlistType.out and SlistTest.screen contain the output. The UML diagram for SortedType is identical to that for the UnsortedType, except for the name of the class. SortedType length: int currentpos: int listdata: array +SortedType() +MakeEmpty(): void +GetLength(): int +IsFull(): bool +RetrieveItem(item:ItemType&, found: bool&): void +InsertItem(item:ItemType): void +DeleteItem(item:ItemType): void +ResetList(): void +GetNextItem(item:ItemType&): void

17 41582_CH04_DALECPP.qxd 9/22/06 11:04 AM Page Dynamically Allocated Arrays Dynamically Allocated Arrays Wouldn't it be nice if we could find a technique for the client to be able to specify the maximum number of items on the list at run time? And of course, we wouldn t be asking if C++ didn t provide a way. We can let the maximum number of items be a parameter to a class constructor. But the implementation structure is an array, and doesn t the compiler need to know at compile time what the size of an array is to be? Yes, it does if the array is in static storage, but memory for the array can be allocated at run time if we let it be in dynamic storage (the free store or heap). This change requires the following changes in the class definition: public: SortedType(int max); // max is maximum list size SortedType(); // Default size is 500 // Rest of the prototypes go here. private: int length; int maxlist; // Maximum number of list items ItemType* info; // Pointer to dynamically allocated memory int currentpos; ; When declaring a class object, the client can specify the maximum number of list items by using the parameterized constructor: SortedType mylist(100); // List of at most 100 items. Or the client can accept the default size of 500 by using the default constructor: SortedType yourlist; Within the function definition for each constructor, the idea is to use the new operator to allocate an array of exactly the desired size. Earlier we saw that the expression new SomeType allocates a single variable of type SomeType on the free store and returns a pointer to it. To allocate an array, you attach to the data type name the array size in brackets: new AnotherType[size]. In this case, the new operator returns the

18 41582_CH04_DALECPP.qxd 9/22/06 11:04 AM Page Chapter 4: ADT Sorted List base address of the newly allocated array. Here are the implementations of the Sorted- Type constructors: SortedType::SortedType(int max) maxlist = max; length = 0; info = new ItemType[maxList]; SortedType::SortedType() maxlist = 500; length = 0; info = new ItemType[maxList]; Notice that info is now a pointer variable, not an array name. It points to the first element of a dynamically allocated array. However, a basic fact in C++ is that you can attach an index expression to any pointer not only an array name as long as the pointer points to an array. Therefore info can be indexed exactly as it was when it was defined as an array of type ItemType (see Figure 4.5). Thus, only one member function needs to be changed: IsFull. bool SortedType::IsFull() return (lenth == maxlist); We do need to use a class destructor. When the list goes out of scope, the memory allocated to top, maxlist, and items is deallocated, but the array that items points to is not. To deallocate an array, insert brackets between the word delete and the name of the pointer. SortedType::~SortedType() delete [] info; Before we leave this SortedType implementation, let s ask if it s necessary to provide both a parameterized constructor and a default constructor. Isn t the parameterized constructor good enough? In most cases, yes. However, the user may want to declare an array of list objects, in which case the parameterized constructor cannot be used. (Remember the rule: If a class has any constructors at all and an array of class objects is declared, one of the constructors must be the default constructor, and it is invoked for

19 41582_CH04_DALECPP.qxd 9/22/06 11:04 AM Page Implementing the Sorted List as a Linked Structure 209 Class object length maxlist 1 5 info currentpos [0] [1] Free store Accessed as: info[0] info[1] [2] [3] [4] info[4] Figure 4.5 A list in which the array is in dynamic storage each element in the array.) Therefore, it s wisest to include a default constructor in the SortedType class to allow client code like this: SortedType SortedGroup[10]; // 10 sorted lists, each of size Implementing the Sorted List as a Linked Structure When writing the array-based implementation of the Sorted List ADT, we found that we had to change only InsertItem and DeleteItem from the Unsorted List versions, but that RetrieveItem could be made more efficient. Because both InsertItem and DeleteItem must search the list, let s look at RetrieveItem first. Function RetrieveItem For the unsorted version, we took the array-based algorithm and changed the array notation to linked notation. Let s try that approach again.

20 41582_CH04_DALECPP.qxd 9/22/06 11:04 AM Page Chapter 4: ADT Sorted List RetrieveItem Set location to listdata Set found to false Set moretosearch to (location!= NULL) while moretosearch AND NOT found switch (item.comparedto(location->info)) case GREATER : Set location to location->next Set moretosearch to (location!= NULL) case EQUAL : Set found to true Set item to location->info case LESS : Set moretosearch to false Let s look at this algorithm and be sure that the substitutions do what we want by examining the value of location at the end. There are three cases here instead of two: 1. location = NULL. If we reach the end of the list without finding an item whose key is equal to item s key, then the item is not in the list. location correctly has the value NULL (see Figure 4.6a, assuming the people s names are in alphabetical order). 2. item.comparedto(location->info) = EQUAL. In this case, we have found the element within the list and have copied it into item (see Figure 4.6b, assuming the people s names are in alphabetical order). (a) Retrieve Sarah listdata Alex Chris John Kit moretosearch: found: location: false false NULL (b) Retrieve Chris listdata Alex Chris John Kit moretosearch: found: true true location Figure 4.6 Retrieving an item in an unsorted linked list

21 41582_CH04_DALECPP.qxd 9/22/06 11:04 AM Page Implementing the Sorted List as a Linked Structure 211 Retrieve Kate listdata Alex Chris John Kit moretosearch: found: false false location Figure 4.7 Retrieving an item that is not there 3. item.comparedto(location->info) = LESS. In this case, we have passed the location where the item belongs, so it isn t in the list (see Figure 4.7). Having looked at all three cases, we can again code this algorithm, being reasonably confident that it is correct. We use the relational operators here as well. void SortedType::RetrieveItem(ItemType& item, bool& found) bool moretosearch; NodeType* location; location = listdata; found = false; moretosearch = (location!= NULL); while (moretosearch &&!found) if (location->info < item) location = location->next; moretosearch = (location!= NULL); else if (item == location->info) found = true; item = location->info; else moretosearch = false;

22 41582_CH04_DALECPP.qxd 9/22/06 11:04 AM Page Chapter 4: ADT Sorted List Function InsertItem We only had to substitute the pointer expressions for the corresponding index expressions in RetrieveItem. Does this technique work for InsertItem? Well, we know that we don t have to shift any elements as we did in an array, so let s make the substitutions up to that point and see. InsertItem Set location to listdata Set moretosearch to (location!= NULL) while moretosearch switch (item.comparedto(location->info)) case GREATER : Set location to location->next Set moretosearch to (location!= NULL) case LESS : Set moretosearch to false When we exit the loop, location is pointing to the location where item goes. That s correct. (See Figure 4.7.) We just need to get a new node, put item into the info member, put location into the next member, and put the address of the new node in the next member of the node before it (the node containing John). Oops! We don t have a pointer to the node before it. We must keep track of the previous pointer as well as the current pointer. When a similar problem arose with DeleteItem in the unsorted version, we compared one item ahead ((location->next)->info). Can we do that here? No. We could use that technique because we knew that the item for which we were searching was present in the list. Here we know that the item for which we are searching is not in the list. If the new item was supposed to go at the end of the list, this algorithm would crash because location->next would be NULL. (See Figure 4.8.) We could change the way of determining moretosearch, but an easier method for handling this situation exists. We use two pointers to search the list, with one pointer always trailing one node behind. We call the previous pointer predloc and let it trail Insert Kate listdata Alex Chris John Kit moretosearch: true location Figure 4.8 Inserting at the end of the list

23 41582_CH04_DALECPP.qxd 9/22/06 11:04 AM Page Implementing the Sorted List as a Linked Structure 213 (a) pred Loc location listdata Alex Chris John Kit (b) Set predloc to location pred Loc location listdata Alex Chris John Kit (c) Set location to Next(location) pred Loc location listdata Alex Chris John Kit Figure 4.9 The inchworm effect one node behind location. When ComparedTo returns GREATER, we advance both pointers. As Figure 4.9 shows, the process resembles the movement of an inchworm. predloc (the tail of the inchworm) catches up with location (the head), and then location advances. Because no node precedes the first one, we initialize predloc to NULL. Now let s summarize these thoughts in an algorithm: InsertItem(item) Revised Set location to listdata Set predloc to NULL Set moretosearch to (location!= NULL) while moretosearch switch (item.comparedto(location->info)) case GREATER : Set predloc to location Set location to location->next Set moretosearch to (location!= NULL) case LESS : Set moretosearch to false Set newnode to the address of a newly allocated node Set newnode->info to item Set newnode->next to location Set predloc->next to newnode Increment length

24 41582_CH04_DALECPP.qxd 9/22/06 11:04 AM Page Chapter 4: ADT Sorted List Let s do an algorithm walk-through before we code it. There are four cases: the new item goes before the first element, between two other elements, comes after the last element, or is inserted into an empty list. (See Figure 4.10.) If we insert at the first element (Figure 4.10a), Alex compared to Becca returns LESS, and we exit the loop. We store location into newnode->next and newnode into predloc->next. Whoops! The program crashes because predloc is NULL. We must check whether predloc is NULL, and if it is, we must store newnode into listdata rather than predloc->next. What about the in-between case? Inserting Kit (Figure 4.10b) leaves location pointing to the node with Lila and predloc pointing to the node with Kate. newnode->next points to the node with Lila; the node with Kate points to the new node. That s fine. What about when we insert at the end? Inserting Kate (Figure 4.10c) leaves location equal to NULL, and predloc pointing to the node with Chris. NULL is stored in newnode->next; newnode is stored in the next member of the node containing Chris. Does the algorithm work when the list is empty? Let s see. location and predloc are both NULL, but we store newnode in listdata when predloc is NULL, so there isn t a problem. (See Figure 4.10d.) Now we can code the function InsertItem. void SortedType::InsertItem(ItemType item) NodeType* newnode; // Pointer to node being inserted. NodeType* predloc; // Trailing pointer. NodeType* location; // Traveling pointer. bool moretosearch; location = listdata; predloc = NULL; moretosearch = (location!= NULL); // Find insertion point. while (moretosearch) if (location->info < item) predloc = location; location = location->next; moretosearch = (location!= NULL); else moretosearch = false; // Prepare node for insertion. newnode = new NodeType;

25 41582_CH04_DALECPP.qxd 9/22/06 11:04 AM Page Implementing the Sorted List as a Linked Structure 215 (a) Insert Alex (goes at the beginning) listdata Becca predloc Alex newnode location (b) Insert Kit (goes in the middle) listdata John Kate Lila predloc Kit location newnode (c) Insert Kate (goes at the end) listdata Alex Chris predloc location Kate newnode (d) Insert John (into an empty list) listdata John predloc location newnode Figure 4.10 Four insertion cases

26 41582_CH04_DALECPP.qxd 9/22/06 11:04 AM Page Chapter 4: ADT Sorted List newnode->info = item; // Insert node into list. if (predloc == NULL) newnode->next = listdata; listdata = newnode; else newnode->next = location; predloc->next = newnode; length++; // Insert as first. Function DeleteItem As in the case of RetrieveItem and InsertItem, the DeleteItem algorithm begins with a search. Here we exit the searching loop when item.comparedto(location-> info) returns EQUAL. Once we have found the item, we delete it. Because our precondition states that the item to be deleted is present in the list, we have a choice. We can use the unsorted list algorithm exactly as it is or we can write an algorithm that is the mirror image of the insertion. We leave the coding of the new algorithm to you as an exercise. Figure 4.11 illustrates the four cases that occur. (a) Delete only list node (Delete David) NULL listdata David predloc location (b) Delete first list node (Delete David) listdata David Joshua Leah Miriam predloc location Figure 4.11 Deleting from a linked list

27 41582_CH04_DALECPP.qxd 9/22/06 11:04 AM Page Implementing the Sorted List as a Linked Structure 217 (c) Delete middle node (Delete Leah) listdata David Joshua Leah Miriam predloc location (d) Delete last node (Delete Miriam) NULL listdata David Joshua Leah Miriam predloc location Figure 4.11 (continued) Code Here are the specification and implementation files for the linked version of class SortedType, with reduced documentation. Note that we have included a destructor. #include "ItemType.h" // Header file for Sorted List ADT. struct NodeType; class SortedType public: SortedType(); ~SortedType(); // Class constructor // Class destructor bool IsFull() const; int GetLength() const; void MakeEmpty(); void RetrieveItem(ItemType& item, bool& found); void InsertItem(ItemType item); void DeleteItem(ItemType item);

28 41582_CH04_DALECPP.qxd 9/22/06 11:04 AM Page Chapter 4: ADT Sorted List void ResetList(); void GetNextItem(ItemType&); private: NodeType* listdata; int length; NodeType* currentpos; ; struct NodeType ItemType info; NodeType* next; ; SortedType::SortedType() // Class constructor length = 0; listdata = NULL; bool SortedType::IsFull() const NodeType* location; try location = new NodeType; delete location; return false; catch(bad_alloc exception) return true; int SortedType::GetLength() const return length; void SortedType::MakeEmpty() NodeType* tempptr;

29 41582_CH04_DALECPP.qxd 9/22/06 11:04 AM Page Implementing the Sorted List as a Linked Structure 219 while (listdata!= NULL) tempptr = listdata; listdata = listdata->next; delete tempptr; length = 0; void SortedType::RetrieveItem(ItemType& item, bool& found) bool moretosearch; NodeType* location; location = listdata; found = false; moretosearch = (location!= NULL); while (moretosearch &&!found) switch(item.comparedto(loction->info) case GREATER: location = location->next; moretosearch = (location!= NULL); break; case EQUAL: found = true; item = location->info; break; case LESS: moretosearch = false; break; void SortedType::InsertItem(ItemType item) NodeType* newnode; // pointer to node being inserted NodeType* predloc; // trailing pointer NodeType* location; // traveling pointer bool moretosearch; location = listdata; predloc = NULL; moretosearch = (location!= NULL);

30 41582_CH04_DALECPP.qxd 9/22/06 11:04 AM Page Chapter 4: ADT Sorted List // Find insertion point. while (moretosearch) switch(item.comparedto(location->info)) case GREATER: predloc = location; location = location->next; moretosearch = (location!= NULL); break; case LESS: moretosearch = false; break; // Prepare node for insertion newnode = new NodeType; newnode->info = item; // Insert node into list. if (predloc == NULL) // Insert as first newnode->next = listdata; listdata = newnode; else newnode->next = location; predloc->next = newnode; length++; void SortedType::DeleteItem(ItemType item) NodeType* location = listdata; NodeType* templocation; // Locate node to be deleted. if (item.comparedto(listdata->info) == EQUAL) templocation = location; listdata = listdata->next; // Delete first node. else

31 41582_CH04_DALECPP.qxd 9/22/06 11:04 AM Page Implementing the Sorted List as a Linked Structure 221 while ((item.comparedto(location->next)->info)!= EQUAL) location = location->next; // Delete node at location->next templocation = location->next; location->next = (location->next)->next; delete templocation; length ; void SortedType::ResetList() currentpos = NULL; void SortedType::GetNextItem(ItemType& item) if (currentpos == NULL) currentpos = listdata; item = currentpos->info; currentpos = currentpos->next; SortedType::~SortedType() NodeType* tempptr; while (listdata!= NULL) tempptr = listdata; listdata = listdata->next; delete tempptr; Comparing Sorted List Implementations Methods applied to a dynamically allocated array behave exactly the same as those applied to a statically allocated array so we group them together in the following discussion. We developed three algorithms for RetrieveItem in an array-based list: a sequential search, a sequential search with an exit when the place is passed where the item would be if present, and a binary search. The first two have order O(N). What about the

32 41582_CH04_DALECPP.qxd 9/22/06 11:04 AM Page Chapter 4: ADT Sorted List binary search algorithm? We showed a table comparing the number of items searched in a linear search versus a binary search for certain sizes of lists. How do we describe this algorithm using Big-O notation? To figure this out, let s see how many times we can split a list of N items in half. Assuming that we don t find the item we are looking for at one of the earlier midpoints, we have to divide the list log 2 N times at the most, before we run out of elements to split. In case you aren t familiar with logs, 2 log 2 N = N That is, if N = 1024, log 2 N = 10 (2 10 = 1024). How does that apply to our searching algorithms? The sequential search is O(N); in the worst case, we would have to search all 1024 elements of the list. The binary search is O(log 2 N); in the worst case we would have to make log 2 N + 1, or 11, search comparisons. A heuristic (a rule of thumb) tells us that a problem that is solved by successively splitting it in half is an O(log 2 N) algorithm. Figure 4.12 illustrates the relative growth of the sequential and binary searches, measured in number of comparisons. The first two searches can be implemented in a linked list but a binary search cannot. (How do you get directly to the middle of a linked list?) Therefore, the array-based algorithm for searching a list is faster than the linked version if the binary search algorithm is used. In both sorted list implementations, the InsertItem function uses a sequential search to find the insertion position; therefore, the search parts of the algorithms have O(N) complexity. The array-based list must also move down all the elements that follow the insertion position to make room for the new element. The number of elements to be moved ranges from 0, when we insert at the end of the list, to length, when we insert at the beginning of the list. So the insertion part of the algorithm also has O(N) complexity for the arraybased list. Because O(N) + O(N) = O(N), the sequential list s InsertItem operation has O(N). Even if we used the binary search to find where the item belongs (O(log 2 N)), the items would have to be moved to make room for the new one (O(N)). O(log 2 N) + O(N) is O(N). The insertion part of the algorithm for the linked list representation simply requires the reassignment of a couple of pointers. This makes the insertion task O(1) for a linked list, which is one of the main advantages of linking. However, adding the insertion task to the search task gives us O(N) + O(1) = O(N) the same Big-O approximation as for the Number of comparisons Linear search O(N) Binary search O(log 2 N) N (Number of elements) Figure 4.12 Comparison of linear and binary searches

33 41582_CH04_DALECPP.qxd 9/22/06 11:04 AM Page Implementing the Sorted List as a Linked Structure 223 sequential list! Doesn t the linking offer any advantage in efficiency? Perhaps. But remember that the Big-O evaluations are only rough approximations of the amount of work that an algorithm does. The DeleteItem function is similar to InsertItem. In both implementations, the search task is performed, an O(N) operation. Then the sequential list s delete operation deletes the element by moving up all the subsequent elements in the list, which adds O(N). The whole function is O(N) + O(N), or O(N). The linked list deletes the element by unlinking it from the list, which adds O(1) to the search task. The whole function is O(N) + O(1), or O(N). Thus both DeleteItem operations are O(N); for large values of N, they are roughly equivalent. The fact that two operations have the same Big-O measure does not mean that they take the same amount of time to execute, however. The sequential implementation requires, on average, a great deal of data movement for both InsertItem and DeleteItem. Does all this data movement really make any difference? It doesn t matter too much in textbook examples; the lists are very small. If there are 1000 items in a list, however, the data movement starts to add up. Table 4.3 summarizes the Big-O comparison of the sorted list operations for sequential and linked implementations. Table 4.3 Big-O Comparison of Sorted List Operations Array Implementation Linked Implementation class constructor O(1) O(1) MakeEmpty O(1) O(N) IsFull O(1) O(1) GetLength O(1) O(1) ResetList O(1) O(1) GetNextItem O(1) O(1) RetrieveItem O(N)* O(N) InsertItem Find O(N)* O(N) Insert O(N) O(1) Combined O(N) O(N) DeleteItem Find O(N)* O(N) Delete O(N ) O(1) Combined O(N) O(N) *O(log 2 N) if a binary search is used.

34 41582_CH04_DALECPP.qxd 9/22/06 11:04 AM Page Chapter 4: ADT Sorted List 4.4 Comparison of Unsorted and Sorted List ADT Algorithms Table 4.4 shows both implementations for both the Unsorted List ADT and the Sorted List ADT. The big difference in the complexity between the Unsorted List and the Sorted List lies in the insertion algorithm. The Unsorted List is O(1) and the Sorted List is O(N). The array-based and linked insertion into a sorted list are both O(N), but the array-based version is actually O(2N); we just throw away the constant. Does that mean we should ignore the differences in constants? No; if two algorithms have the same complexity, then you can look at the constants. Think of the common orders of complexity as being bins into which we sort algorithms (Figure 4.13). For small values of the size factor, an algorithm in one bin may actually be faster than the equivalent algorithm in the next-more-efficient bin. As the size factor increases, the differences among algorithms in the different bins gets larger. When choosing between algorithms within the same bin, you look at the constants to determine which to use. Table 4.4 Big-O Comparison of List Operations in Each Implementation Function Unsorted List ADT Sorted List ADT Array-based Linked Array-based Linked Class constructor O(1) O(1) O(1) O(1) MakeEmpty O(1) O(N) O(1) O(N) IsFull O(1) O(1) O(1) O(1) GetLength O(1) O(1) O(1) O(1) ResetList O(1) O(1) O(1) O(1) GetNextItem O(1) O(1) O(1) O(1) RetrieveItem O(N) O(N) linear search O(N) O(N) binary search O(log 2 N) InsertItem Find O(1) O(1) O(N) O(N) Insert O(1) O(1) O(N) O(1) Combined O(1) O(1) O(N) O(N) DeleteItem Find O(N) O(N) O(N) O(N) Delete O(1) O(1) O(N) O(1) Combined O(N) O(N) O(N) O(N)

35 41582_CH04_DALECPP.qxd 9/22/06 11:04 AM Page Bounded and Unbounded ADTs 225 0(1) 0(log 2 N) 0(N) 0(Nlog 2 N) 0(N*N) Figure 4.13 Complexity bins 4.5 Bounded and Unbounded ADTs A bounded ADT is one where there is a logical limit on the number of items to be stored in the structure. An unbounded ADT is one where there is no logical limit. We tend to think of array-based structures as being bounded and linked structures as being unbounded. However, this is an implementation interpretation, not a logical one. Bounded ADT An ADT for which there is a logical limit on the number of items in the structure Unbounded ADT An ADT for which there is no logical limit on the number of items in the structure For example, a client may have a reason for knowing that the maximum number of items on a list will never exceed a certain value, that the list is logically bounded. If an attempt to add an additional item is made, the client wants to be notified by having an exception thrown. Thus far, we have implemented our list ADTs as physically bounded (array-based) or physically unbounded (linked) without regard to the logical issue. We could make an array-based implementation unbounded by having the class increase the size of the array when the array is full and copying the current array elements into the new array. This is easy to do if the array is dynamically allocated. We could make a linked implementation bounded by requiring the client to provide MAX_ITEMS and comparing the length to it before an item is added. The moral here is that the documentation for an ADT must state whether the implementation is bounded or unbounded. If bounded, the client must have the facility, probably through a constructor, to set the size of the structure, and an exception must be thrown if an attempt to go beyond that size is made. If unbounded, the documentation must state that IsFull returns true only if the program runs out of memory. The client then makes a choice of which implementation to use based on whether the ADT is logically bounded or unbounded.

36 41582_CH04_DALECPP.qxd 9/22/06 11:04 AM Page Chapter 4: ADT Sorted List 4.6 Object-Oriented Design Methodology There are four stages to the object-oriented design that we present. Brainstorming is the stage in which we make a first pass at determining the classes in the problem. Filtering is the stage in which we go back over the proposed classes determined in the brainstorming stage to see if any can be combined, any are not needed, or if any are missing. Each class that survives the filtering stage is recorded on a CRC card. Scenarios is the stage in which the behavior of each class is determined. Because each class is responsible for its own behavior, we call the behaviors responsibilities. In this stage, what if questions are explored to be sure that all situations are examined. When all of the responsibilities of each class have been determined, they are recorded on the class s CRC card, along with the names of any other classes with which it must collaborate (interact) to complete its responsibility. In Responsibility Algorithms, the last stage, we write the algorithms for each of the responsibilities outlined on the CRC cards. Now you can see where the term CRC comes from: Class, Responsibility, and Collaboration. Although these techniques are designed to be applied in groups, we can apply them to our own individual thought processes as well, so let s look at each of these stages in a little more detail. Brainstorming Just exactly what is brainstorming? The dictionary defines it as a group problem-solving technique that involves the spontaneous contribution of ideas from all members of the group. 1 Brainstorming brings to mind a movie or TV show where a group of bright young people toss around ideas about an advertising slogan for the latest revolutionary product. This picture seems at odds with the traditional picture of a computer analyst working alone in a closed, windowless office for days who finally jumps up shouting Ah ha! As computers have become more powerful, the problems that can be solved have become more and more complex, and the picture of the genius locked in a windowless room has become obsolete. Solutions to complex problems need new and innovative solutions based on collective Ah ha! s. Belin and Simone list four principles of successful brainstorming. 2 First and foremost, all ideas are potential good ideas. It is imperative that the members of the group don t censor their own ideas or make judgments out of hand on other s ideas. The next principle relates to pace: Think fast and furiously first, and ponder later. The faster the pace at first, the better the creative juices flow. Thirdly, give every voice a turn. To slow down those predisposed to hog the conversation and spur those reluctant to talk, use a rotation. Continue the pattern until team members are truly forced to pass because they are out of ideas. Lastly, a little humor can be a powerful force. Humor helps convert a random group into a cohesive team. 1 Webster s New Collegiate Dictionary. 2 Belin, D. and Simone S. S. The CRC Card Book. Addison-Wesley