Data Structures

1. Andreas Savva Data Structures Chapter 1 Programming Principles

2. Data Structures Type of data Structure of data

3. Data Type • Consists of two parts: • Set of values • Set of operations that act on the values • Example : Integer data type • Values - whole numbers in some defined range • Operations - add, subtract, multiply, divide, etc.

4. Data Structure • Consists of two parts: • Collection of elements each of which is either a data type or another data structure. • A set of associations or relationships (structure) involving the collection of elements.

5. Examples – Data Structure • Array • Sequence of elements (data types) • Position association among the elements • Record • Collection of data into a single structure • No association

6. Linear Structure Hierarchical (Tree) structure Graph structure Set structure Classification - Data Structures • Unique predecessor • Unique successor • Unique predecessor • Many successors • Many predecessors • Many successors • No predecessor • No successor

7. Linear Structure Hierarchical (Tree) structure Graph structure Set structure Examples • Stack • Queue • Family Tree • Computer Directories • Computer Network • London Underground • You - Students in this class

8. Why do we need data structures? Example – Towns Data Structure • You need to visit all houses in two towns once only. • In each town you start and finish at house number 1. • All roads are the same length. • Same number of houses in each town.

9. Town 1 Town 2 1 2 3 2 1 3 8 4 8 4 7 5 6 7 6 5 In town 1 you walk twice as far as in town 2. Why? Because the structures are different.

10. Choosing a data structure • The process involves: • analyzing the problem, • determining basic operations needed, • selecting the data structure.

11. Choosing the right data structure • The right data structure will make your operations simple and efficient. • The wrong data structure will make your operations complex and inefficient.

12. Abstract Data Types (ADT) • A module (object) containing: • the data structure, • the associated operations (subprograms). • Details of the module are hidden from the user (encapsulation). • This is called data abstraction. • Modules are stored as • Unitin Pascal,Classin C++ and Java

13. Abstract Data Types (ADT) • Data cannot be accessed directly. • Data can only be accessed indirectly via the subprograms (methods) associated with the data. • Thus, the module contains: • The data structure. • Subprograms to access and/or modify the data structure.

14. C++ Classes, Objects, and Methods • A class collects data and the methods used to access or change the data. • Such a collection of data and methods is called an object belonging to the given class. • Every class consists of members that represent either variables (called data members) or functions (called methods or member functions). The member functions of a class are normally used to access or alter the data members. • Clients (user programs) can declare and manipulate objects of that class.

15. Information Hiding • A client does not need to know how the data are actually stored or how the methods are programmed. This important programming strategy is called information hiding. • Data members and methods available to a client are called public. • Private variables and functions may be used in the implementation of the class, but are not available to a client. Methods of a class are public Functions in a class are private

16. Comparison • Abstract Data Types • High level description – logical picture of the data, and operations that manipulate the data. • Implementation of program is independentto the data structure. • Implementation of program is concerned with what it can do. • NOT Abstract Data Types • Concrete description – collection of data types & operations that store and retrieve individual elements. • Implementation of program is dependant to the data structure. • Implementation of program is concerned with how a task is done.

17. Example – Abstract Data Type • Main activities for operating a car are: • steering, accelerating, braking • The design of a car can be viewed as an ADT with operations: • steer, accelerate, brake • Two cars may implement these operations in different ways. • Most drivers can operate any car since the ADT presents a uniform method of operation.

18. Programming • Assumption: • You can design and write programs. • This Course: • Uses C++ as a tool. • Will not teach you how to program.

19. Programming Principles • We must learn to observe important principles of program design. • We usually ignore them when we write small programs. • BUT ignoring them when writing large projects could be disastrous.

20. Problems of large programs • More difficult to maintain them than to write them. • In time there will be new requests on the program, and if it is not well-designed or if the data is not well structured it will be impossible to restructure it and the program will become unusable. • It will cost less to write another program from scratch than maintaining the existing one. • The approach “First make your program work and then make it pretty” may be effective for small programs but not for large ones.

21. Data Structure Common and compatible Project Sub-problem Program Design • Divide the problem into smaller problems until they become of manageable size. • Each part of a program must be well organized, clearly written or else its structure will have been forgotten at some time later or will not be understood by other programmers. You must form good programming habits from the beginning.

22. Choice of Data Structures • The most important aspect in algorithm design is the way in which the data of the program is stored: • How they are arranged in relation to each other. • Which data are kept in memory. • Which are calculated when needed. • Which are kept in files, and how this files are arranged. Program Testing • The difficulty of debugging a program increases much faster than its size. A program twice the size of another will likely to not take twice as long to debug, but most probably, four times as long. • Many large programs (such as operating systems) are put into use still containing errors that the programmers have not spotted. • Sometimes projects that have consumed years of effort must be discarded because it is impossible to discover why they will not work.

23. Program Correctness • If we do not wish such a fate to our projects, then we must use methods that: • Reduce the number of errors, making it easier to spot those that remain. • Enable us to verify in advance that our algorithms are correct. • Provide us with ways to test our programs so that we can be reasonably confident that they will not misbehave. Maintenance • Since new demands will arise in the future it is important that a large project is written to make it as easy as possible to be understood and modified.

24. Case Study • The Game of Life • Introduced by the British mathematician J.H. Conway in 1970. • It is a simulation, not a game with players.

25. Rules for the Game of Life • It takes place on an unbounded rectangular grid in which each cell can either be occupied by an organism or not. Occupied cells are called alive; unoccupied cells are called dead. Which cells are alive changes from generation to generation according to the number of neighboring cells that are alive, as follows: • The neighbors of a given cell are the eight cells that touch it vertically, horizontally, or diagonally. • If a cell is alive but either has no neighboring cells alive or only one alive, then in the next generation the cells dies of loneliness. • If a cell is alive and has four or more neighboring cells also alive, then in the next generation the cell dies of overcrowding. • A living cell with either two or three living neighbors remains alive in the next generation. • If a cell is dead, then it will become alive if it has exactly three neighboring cells that are alive. All other dead cells remain dead in the next generation. • All births and deaths take place at exactly the same time.

26. Example 1 Configuration Living neighbors By rule 2 both the living cells will die in the next generation and rule 5 shows that no cells will become alive, so that configuration dies out.

27. Example 2 Each of the living cells has a neighbor count of three, and hence remain alive, but the dead cells all have neighbor counts of two or less, and none of them becomes alive. Thus all new configurations will be identical to this one.

28. Working Example

29. Another Example The two configuration continue to alternate from generation to generation.

30. The Algorithm • Set up an initial Life configuration. • Print the Life configuration. • While the user wants to see further configurations: • Update the configuration by applying the rules of the Life game. • Print the current configuration.

31. The Class Life enumstatus {dead,alive}; class Life { public: void initialize(); void print() const; void update(); private: int neighbor_count(int, int) const; status grid[maxrow][maxcol]; };

32. The Main Program int main() { Life configuration; welcome(); configuration.initialize(); configuration.print(); cout << "Continue viewing new generations?" << endl; while (user_says_yes()) { configuration.update(); configuration.print(); cout << "Continue viewing new generations?" << endl; } return 0; }

33. Initialize void Life::initialize() { int row,col; for (row=0;row<maxrow;row++) for (col=0;col<maxcol;col++) grid[row][col] = dead; cout << "Enter row and column of living cells and finish with -1 -1" << endl; while ((row!=-1) || (col!=-1)) { cin >> row >> col; if (row==-1 && col==-1) cout << "Done" << endl; else if ((row<0) || (row>=maxrow)) cout << "Row out of range" << endl; else if ((col<0) || (col>=maxcol)) cout << "Column out of range" << endl; else grid[row][col] = alive; } }

34. Print void Life::print() const { }

35. Count Neighbors int Life::neighbor_count (int row, int col) const { }

36. Update void Life::update () { }

37. User Reply bool user_says_yes() { char c; bool initial_response = true; do { if (initial_response) cout << "(y/n)?"; else cout << "Respond with either y or n: "; initial_response = false; do { cin >> c; } while (c=='\n' || c==' ' || c=='\t'); } while (c!='y' && c!='Y' && c!='n' && c!='N'); return (c=='y' || c=='Y'); }

38. Programming Guidelines • Choose meaningful names. • Use common prefixes or suffixes to associate names of the same general category, i.e. input_file out_file total_file • Be careful with the use of the letters “I” and “O”, i.e. I = 1; x = 1; x = I; x = O; x = 0; • Avoid global variables when possible. • Avoid side-effects (changing the values of global variables). • Keep the functions short – less than a page.

39. Documentation Guidelines • The reading time for programs is much more than the writing time. “Make your program readable”. • Place a prologue at the beginning of your program. • When each variable, constant, or type is declared explain what it is and how it is used. Better still, make this information evident from the name. • Introduce each significant part of your program (paragraph or function) and indicate where it ends if it is not obvious. • Avoid comments that parrot what the code does, i.e. count++ // Increase counter by 1 • The code itself should explain how the program works. The documentation should explain why it works and what it does. • Modify the comments along with the code. • Add pre-conditions and post-conditions to your functions.

40. Programming Questions • Does the program solve the problem that is requested? • Does the program work correctly under all conditions? • Does the program have a good user interface? • Is the program logically and clearly written? • Is the program well documented? • Does the program make efficient use of time and space? • Does the program run on the right hardware? • Can the program handle the maximum size of input?