BAGS

          |   |
          |   |
         / 17  \
        /    23 \
       | 4       |
       |   11  17|
        \_______/
      

• Unordered collection of items
• Duplication allowed
• Application: lottery drawing

What can we do with bags?

• Put an item in a bag:

  
         17
         |
         |                                                 
         v                                                 
       |   |                            |   |   
       |   |                            |   |   
      /     \         =====>           /     \  
     /       \                        /       \ 
    | 4       |                      | 4       |
    |         |                      |     17  |
     \_______/                        \_______/ 
  
  
  

• Grab an arbitrary item from the bag:

       |   |                       4    |   |   
       | ^ |                            |   |   
      /  |  \         =====>           /     \  
     /   |   \                        /       \ 
    | 4--|    |                      |         |
    |     17  |                      |     17  |
     \_______/                        \_______/ 
  

• Count the number of items in a bag:

  
            |   |
            |   |
           / *   \
          /    *  \   =====>   5
         | *       |
         |   *   * |
          \_______/
        
  

• Is a bag empty?

  
            |   |
            |   |
           /     \
          /       \   =====>   Yes
         |         |
         |         |
          \_______/
  
  
            |   |
            |   |
           / *   \
          /    *  \   =====>   No
         | *       |
         |   *   * |
          \_______/
  
  

• Is a bag full?

  
            |***|
            |***|
           /*****\
          /*******\   =====>   Yes
         |*********|
         |*********|
          \-------/
  
  
            |   |
            |   |
           / *   \
          /    *  \   =====>   No
         | *       |
         |   *   * |
          \_______/
  
  

• Later, we may look at more advanced bag operations, such as:
  • is item x in bag b? (how many x's occur in b?)
  • remove item x from bag b
  • merge contents of two bags

Making and throwing away bags

• All bag operations presented thus far (not surprisingly) rely on the existence of bags.
• We need an operation to create new bags - a constructor.
• To avoid "clutter," we need an operation to throw bags away - a destructor.

Running a lottery

• Start with an empty bag.
• For each ticket purchased, put an item in the bag.
• Grab an arbitrary item from the bag to see who wins.
• Throw away the bag when done.

• Don't grab if not tickets purchased.
• Don't sell tickets if bag is full.
• Use number of items in bag to compute odds.

Summary of our "Bag of tricks" (bag operations)

• Construct a new, empty bag
• Check if a bag is empty or full
• Count how many items are in a bag
• Insert an item into a bag
• Grab an arbitrary item from a bag

• Count how many occurrences of a given item are in a bag
• Check if two bags are "equal"
• Display the items in a bag

Specifying the Bag class

The specifications for the bag operations can be found in the file bag.h.

The details of how some of the bag operations are specified can be found in the these postscript slides of Main & Savitch.

Some reminders about C++ member functions:

• The keyword const in

  bool Bag::isEmpty() const 

  indicates that the isEmpty member function of the Bag class does not modify the contents of the bag. It is like a static postcondition - a guarantee that after the function is called the state of the Bag will not have changed (static because the compiler can check it).
• In:

  bool Bag::operator==(const Bag& operand) const
              (1)       (2)    (3)
        

  (1), the keyword operator indicates operator overloading - the == operator will have a user-supplied meaning rather than the standard compiler meaning (if there is such a one). (2), the keyword const indicates that the operand, supplied to the function as an argument, will not be modified by the function - it is also like a static postcondition. (3) The & in Bag& indicates that the argument will be passed by reference (the address of operand will be passed) rather than by value (a copy of operand will be passed).
• In:

  friend ostream& operator <<(ostream&, const Bag&)
    (1)     (2)                  (2)
        

  (1), the keyword friend indicates that the function is not a member of the class (in this case the Bag class), but the function still has access to the class' private members. It is not crucial that a user (as opposed to implementer) know a function is a friend - since the user need not know which members are private. (2) ostream is a class defined in the standard C++ library iostream.h for referring to output devices.
• Consider the public member variable declaration in the Bag class:

  static const size_t CAPACITY = 20;
    (1)   (2)    (3)
        

  (1) The keyword static indicates that all bags have the same CAPACITY. (2) The keyword const indicates that CAPACITY cannot change during program execution. (3) The type size_t is defined in the C++ standard library stdlib.h. It is an unsigned (non-negative) integer that is designed for describing how many objects are stored in memory. Since size_t is an unsigned type, beware of the following situation:

  size_t i;
  i = 0;
  i--; // i = i - 1
  // i is not -1, but instead a large positive int
  // this is usually BAD
        

Implementing the Bag class

The details of how some of the bag operations are implemented can also be found in the these postscript slides of Main & Savitch.

Other details are discussed below.

Algorithm for Bag::occurrences(int target):

1. Initialize an answer-counter to 0
2. For each element in the array representing the bag (data), check it if it is equal to the target item we are counting. If so, increment answer-counter.
3. Return the answer-counter.

Bag::grab() - first attempt:

1. (Check the precondition: the bag is not empty.)
2. Select a `random' location in the used part of the data array.
3. Remember the item at that location.
4. Decrement the member variable count
5. For each item past that location, move the item one position backwards in the array.
6. Return the `remembered' item.

int Bag::grab()
{
  int x;
  size_t i;

  i = rand() % count; // i will be in range 0<=i<count
  x = data[i];
  count--;
  for(size_t j = i; j < count; j++)
    data[j] = data[j+1];
  return x;
}
  

An example of calling Bag::grab(). Consider the Bag represented as:

8 4 17 33 4 11 16
      

If the random int i is chosen to be 0 then the resulting array is:

4 17 33 4 11 16
      

Meaning that roughly count number of items of the data array had to be `slid over'. This makes grab slow for large Bags. (Slower than necessary - in fact, it is O(n) - see the notes on computational complexity.)

Building a Better Grab

int Bag::grab()
{
  int x;
  size_t i;

  i = rand() % count;
  x = data[i];
  count--;
  data[i] = data[count];
  return x;
}
    

We would like to be able to formalize the notion that one algorithm is more efficient than another. This motivates our next topic: computational complexity.

1. We can quickly check if bags have same number of total elements. If not we return false. If so, we continue on to the next step.
2. For each item x in b check if x occurs the same number of times in b as it does in c. If not then return false. If so, continue checking items in b.
3. If we make it all the way through b then b and c must be equal so we return true.

• Each call to occurrences takes O(n) operations.
• For each item in bag b, occurrences is called once for b, once for c
• n items in b and c imply 2n*O(n) operations total which makes for a O(n² ) worst-case running-time complexity.
• In the best case, b and c have different sizes and that can be determined in constant time (O(1) operations).

Better Bag equality?

Can we do better? Yes. We can make arrays B,C of the size of the two bags and sort b.data into B and c.data into C. Then b==c if and only if B and C have the same elements in the same order.

How fast is this version of bag equality? 2 sorting operations plus a walk through arrays B, C (which is O(n)), so the complexity it 2*sort-time + O(n). In general, sorting is worse than O(n) so, asymptotically, worst-case time is proportional to the sorting complexity.

For selection sort, bag equality would be O(n² ) again. However, there are O(n*lg(n)) sorting algorithms (which we will learn about later in the semester). In the case of the faster sorting, bag equality can be done in O(n*lg(n)).

Drawbacks to the sorting method of bag equality include the memory overhead for the additional arrays and that for small bags this may actually be slower.