Lab 3
Yuldasheva Sabohatoy
22103N008
Data Sturucture
1 Three criteria for evaluating a data structure for implementing an Abstract Data Type (ADT): Encapsulation, Efficiency, and Correctness.
2 The choice of a data structure for an ADT should match the characteristics and needs of the data values within its domain.
3 Not exposing implementation details in an ADT provides abstraction, separation of concerns, and information hiding, leading to a simpler and more secure interface.
4 Candidate data structures for implementing the Bag ADT include arrays, linked lists, dynamic arrays (e.g., ArrayList), and hash tables.
Top of Form
5 The key difference is that dictionaries (e.g., HashMap) are efficient for implementing the Bag ADT because they can directly map elements to their counts, while lists require manual tracking of counts.
6 Dictionaries are a better choice for the Bag ADT when efficient counting, memory efficiency for sparse bags, fast element lookup, and flexible data types are important considerations
7 Traversal is crucial for working with Abstract Data Types (ADTs) because it allows structured access and manipulation of data within the ADT.
8 In most object-oriented programming languages, you can traverse container types using a "for" loop construct, where you iterate through each element in the container using a loop variable.
9 Custom traversal methods are added to a user-defined ADT when you need specific traversal orders, maintain encapsulation, abstraction, or optimize traversing the ADT's data.
10 The drawback of adding traversal methods for specific operations is a loss of generalization and increased complexity.
11 Providing direct access to the underlying data structure of an ADT breaks encapsulation, jeopardizes data integrity, security, and maintainability, and undermines the abstraction principles of ADTs.
12 An iterator in OOP is a design pattern that allows sequential access to elements in a data structure without exposing its internal details. It's used to traverse user-defined ADTs by defining an iterator interface and implementing it in the ADT to provide a standardized way to iterate through its elements.
13 The Julian day representation allows for calendar date comparisons by providing a continuous count of days that starts from a specified reference point (the Julian Day Epoch) and assigns a unique integer value to each day in history. Here's how it works:
Julian Day Epoch: The Julian day count starts from a specific reference point, such as January 1, 4713 BC (Julian calendar) or November 24, 4714 BC (Gregorian calendar). This point is known as the Julian Day Epoch.
Count of Days: Each day is assigned a unique integer value, incrementing by one for each day that follows the Julian Day Epoch. For example, January 1, 4713 BC, might be assigned the value 0, and each subsequent day is given the next integer.
Consistency: Regardless of calendar changes, such as the transition from the Julian calendar to the Gregorian calendar, which resulted in the omission of several days, the Julian day count remains consistent. This makes it suitable for comparing dates across different calendar systems and for calculating time intervals with precision.
Mathematical Simplicity: The Julian day representation simplifies date arithmetic, making it easy to calculate the difference between two dates by subtracting their Julian day values. This is particularly useful in astronomy, scientific calculations, and calendar conversions.
14 In OOP, you typically use the equality operator (== or equals method) for checking if Date objects represent the same date and comparison operators (>, >=, <, <=) for chronological order comparisons.
15 Date classes often implement only three logical comparison operators (less than, less than or equal to, and equal to) for simplicity, clarity, avoidance of ambiguity, and consistency with conventions and standards.
Top of Form
Top of Form
|
