Understanding Maps and Dictionaries in Large Scale Programming

1. CSC 213 – Large Scale Programming Lecture 13:Dictionary

2. Today’s Goal • Final review of why, when, & how of Maps • Limits of Map ADT & its impact also considered • Compare and contrast Dictionary & Map • Discuss common features found in both ADTs • Consider what are major differences between two • Changes to methods resulting from these differences • Examine 2 ways Dictionary implemented • Effect on performance of each implementation • Based on this, when & why use one of these approach

3. Map-Based Bartender

4. Map-Based Bartender No problem. I’ll have aManhattan ¾ oz sweet vermouth2½ oz bourbon 1 dash bitters1 maraschino cherry1 twist orange peel

5. Map-Based Bartender That’ll be $2 billion I’ll have aManhattan

6. Map-Based Bartender I’ll have aManhattan key value

7. What is a Map? • At simplest level, Map is collection of Entrys • Focus on searching data (or so it appears) • put() adds Entry so key is mapped to value • get() returns valueassociated with key • remove() used to delete an Entry • At most one value per key using a Map

8. Where Maps are Used • Mapgreat when want only one value for a key • Credit card number goes to one account • One person has a given social security number • One definition per word in the dictionary

9. Where Maps are Used • Mapgreat when want only one value for a key • Credit card number goes to one account • One person has a given social security number • One definition per word in the dictionary

10. Limitations of Map • May want to associate multiple values per key • Map key to Sequence of valuespossible solution • But this means Map’s user must handle complexity

11. Limitations of Map • May want to associate multiple values per key • Map key to Sequence of valuespossible solution • But this means Map’s user must handle complexity

12. Dictionary-based Bartender

13. Dictionary-based Bartender No problem. I’ll have aManhattan key value

14. Dictionary-based Bartender Not that Manhattan Sorry. key value

15. Dictionary-based Bartender Not that Manhattan Sorry. How about… key anothervalue

16. Dictionary-based Bartender That’ll be $2 billion Mmmmm... Manhattan key not a anothervalue

17. Dictionary ADT • Dictionary ADT very similar to Map • Hold searchable data in each of these ADTs • Both data structures are collections of Entrys • Convert key to valueusing either concept • Dictionary can have multiple values to one key • 1 value for key is still legal option

18. Dictionary ADT • Dictionary ADT very similar to Map • Hold searchable data in each of these ADTs • Both data structures are collections of Entrys • Convert key to valueusing either concept • Dictionary can have multiple values to one key • 1 value for key is still legal option “awesome”

19. Dictionary ADT • Dictionary ADT very similar to Map • Hold searchable data in each of these ADTs • Both data structures are collections of Entrys • Convert key to valueusing either concept • Dictionary can have multiple values to one key • 1 value for key is still legal option “awesome” • Also many Entryswith same key but different value “cool” “cool”

20. Map vs. Dictionary

21. Map vs. Dictionary MapADT Dictionary ADT • Collection of Entrys • key – searched for • value – cared about • Collection of Entrys • key – searched for • value – cared about

22. Map vs. Dictionary MapADT Dictionary ADT • Collection of Entrys • key – searched for • value – cared about • Implemented with: • List w/ Entrys in order they were added • Collection of Entrys • key – searched for • value – cared about • Implemented with: • List w/ Entrys in order they were added

23. Map vs. Dictionary MapADT Dictionary ADT • Collection of Entrys • key – searched for • value – cared about • Implemented with: • List w/ Entrys in order they were added • List w/ Entrys in increasing order of keys • Collection of Entrys • key – searched for • value – cared about • Implemented with: • List w/ Entrys in order they were added • List w/ Entrys in increasing order of keys

24. Map vs. Dictionary Map ADT Dictionary ADT • Collection of Entrys • key – searched for • value – cared about • Implemented with: • List w/ Entrys in order they were added • List w/ Entrys in increasing order of keys • Hash table • Collection of Entrys • key – searched for • value – cared about • Implemented with: • List w/ Entrys in order they were added • List w/ Entrys in increasing order of keys • Hash table (but harder)

25. Map vs. Dictionary Map ADT DictionaryADT • Collection of Entrys • key – searched for • value – cared about • Implemented with: • List w/ Entrys in order they were added • List w/ Entrys in increasing order of keys • Hash table • key in at most1Entry • Collection of Entrys • key – searched for • value – cared about • Implemented with: • List w/ Entrys in order they were added • List w/ Entrys in increasing order of keys • Hash table (but harder) • Entryscan sharekey

26. Map vs. Dictionary MapADT DictionaryADT • Collection of Entrys • key – searched for • value – cared about • Implemented with: • List w/ Entrys in order they were added • List w/ Entrys in increasing order of keys • Hash table • key in at most1Entry • Collection of Entrys • key – searched for • value – cared about • Implemented with: • List w/ Entrys in order they were added • List w/ Entrys in increasing order of keys • Hash table (but harder) • Entryscan sharekey

27. Changes for Dictionary

28. Using an Unordered List • Simplest implementation uses unordered list • Question is: PositionListor IndexList • Mayscan through list during find or findAll • To see if it matches, check each Position • Stop at first matching key in find method • findAll needs to scan entire list for matches Time needed for PositionList: Time needed for IndexList:

29. Using an Unordered List • Simplest implementation uses unordered list • Question is: PositionListor IndexList • Mayscan through list during find or findAll • To see if it matches, check each Position • Stop at first matching key in find method • findAll needs to scan entire list for matches Time needed for PositionList:O(n) Time needed for IndexList: O(n)

30. Unordered List Details • Mayscan through listin call to remove • To see if a match, check each element • Stop & remove Entryonce (if) it is found • insert goes to end of listto add Entry • Entry created for key-valuepair is returned • Keys not unique, so no checks needed Time needed for PositionList: Time needed for IndexList:

31. Unordered List Details • Mayscan through listin call to remove • To see if a match, check each element • Stop & remove Entryonce (if) it is found • insert goes to end of listto add Entry • Entry created for key-valuepair is returned • Keys not unique, so no checks needed Time needed for PositionList:O(n) &O(1) Time needed for IndexList: O(n) & O(n)

32. Unordered List • Implementation great when adds are common… …but searching slow and not very useful • When would we ever need this implementation?

33. Unordered List • Implementation great when adds are common… …but searching slow and not very useful • When would we ever need this implementation? • Phone records • E-mail backups • Tax receipts by the IRS • Bank’s copy of your credit card orders

34. Unordered List • Implementation great when adds are common… …but searching slow and not very useful • When would we ever need this implementation? • Phone records • E-mail backups • Tax receipts by the IRS • Bank’s copy of your credit card orders

35. Ordered Dictionary • Idea normally associated with Dictionary • Maintains ordered list of key-value pairs • Must maintain Entrys ordered by their key • Faster searching provides performance win Q: “Mom, how do I spell _______?” A: “Look it up.” • Efficiency gains not just for find & findAll • Entrys with same key stored in any order • Only requires that keys be in order only

36. Ordered Dictionary • Iteratorsshouldrespect ordering of Entrys • Should not be a problem, if Entrys stored in order • If O(1) access time, search time is O(log n) • Array-based structure required to hold Entrys • To get immediate access, needs to access by index • Requires IndexList-based implementation

37. Binary Search • Finds key using divide-and-conquer approach • First of many times you will be seeing this approach • Algorithm has problems solved using recursion • Base case 1:No Entrys remain to find the key • Base case 2: At data’s midpoint is matching key • Recursive Step 1: If midpoint too high, use lower half • Recursive Step 2: Use upper half,if midpoint too low

38. Binary Search • low and high params specifying range to check • Would be called with 0 & size() – 1, initially • If l > h, no match possible in this data • Compare with key at midpoint of low & high • Consider steps for find(7): 0 1 3 4 5 7 8 9 11 14 16 18 19 m h l

39. Binary Search • low and high params specifying range to check • Would be called with 0 & size() – 1, initially • If l > h, no match possible in this data • Compare with key at midpoint of low & high • Consider steps for find(7): 0 1 3 4 5 7 8 9 11 14 16 18 19 m h l 0 1 3 4 5 7 8 9 11 14 16 18 19 m h l

40. Binary Search • low and high params specifying range to check • Would be called with 0 & size() – 1, initially • If l > h, no match possible in this data • Compare with key at midpoint of low & high • Consider steps for find(7): 0 1 3 4 5 7 8 9 11 14 16 18 19 m h l 0 1 3 4 5 7 8 9 11 14 16 18 19 m h l 0 1 3 4 5 7 8 9 11 14 16 18 19 m h l

41. Binary Search • low and high params specifying range to check • Would be called with 0 & size() – 1, initially • If l > h, no match possible in this data • Compare with key at midpoint of low & high • Consider steps for find(7): 0 1 3 4 5 7 8 9 11 14 16 18 19 m h l 0 1 3 4 5 7 8 9 11 14 16 18 19 m h l 0 1 3 4 5 7 8 9 11 14 16 18 19 m h l 0 1 3 4 5 7 8 9 11 14 16 18 19 l = m = h

42. Using Ordered Dictionary • findrelies on binary search; takes O(log n)time • Should also start with binary search for findAll() • findAll checks neighbors to find all matches • remove & insertcould use binary search • List shifts elements in addto make hole for element • Would also need to do shift when removing from list • Each takes O(n) total time in worst case as a result

43. Comparing Keys • For all searching, must find matching keys • Cannot rely upon equals()when ordering • Want to be lazy, write code for all types of key • Use <, >, == if keys numeric type, but this is limiting • String also has simple method: compareTo() • General way comparing keys based upon this idea?

44. Comparable<E> Interface • In Java as a standard from java.lang • Defines single method used for comparison • compareTo(E obj)compares instance with obj • Returns intwhich is either negative, zero, positive

45. Ordered Dictionary Example • Easiest to require that keys be Comparable • Now reuse class anywhere by adding interface • Also use standard types like String & Integer • compareTo()in binary search makes it simple int c = k.compareTo(list.get(m).getKey());if (c > 0) {return binarySearch(k, m + 1, h);} else if (c < 0) { return binarySearch(k, l, m - 1);} else { return m;}

46. Before Next Lecture… • Start week #5 assignment • Because of holiday, will be due next Wednesday • Start thinking of design for your project • Due Friday a preliminary copy of this design • Friday sees 1stproblem day on Map & Dictionary • Project test #1 in Lab on Friday, too • Tests your knowledge of group’s submission • No studying needed ifunderstand what group did