1 / 33

The Stack

The Stack. Container ADTs. container collection of objects list-oriented collections positional access relative to position e.g. list keyed collections have a key accessed by key representations contiguous arrays linked linked-structures. Stack.

marged
Télécharger la présentation

The Stack

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. The Stack

  2. Container ADTs • container • collection of objects • list-oriented collections • positional • access relative to position • e.g. list • keyed collections • have a key • accessed by key • representations • contiguous • arrays • linked • linked-structures

  3. Stack • a list (initially empty) of items of some type to which items may be added (pushed) at one end (called the top) and from which items may be removed (popped) only from the same end (i.e. the top) • examples • cafeteria plate stacker • Pez™ candy dispenser • behaviour • example • LIFO ordering • operations • push & pop • viewing • empty • error conditions: • underflow • overflow

  4. Character Stack ADT • item type? • say char • CharStack interface • methods • push • pop • top • empty • exceptions • UnderflowException • OverflowException

  5. Character Stack ADTContiguous Implementation • representation • based on “variable-sized” array • bottom is base (0th element) • top is end of collection (nth element) • implementation • CharStacks package • instance variables • array (elts) and count (top) • constructors • empty stack • methods • exceptions • defensive programming • insertion/deletion don’t affect others O(1)

  6. Character Stack ADTLinked Implementation • representation • top is front • list pointer points to top (front) node • implementation • instance variables • top is list pointer • constructor • empty stack • methods • exceptions • overflow? • Node wrapper class • Serializable • insert/delete at front O(1)

  7. Postfix (RPN) Notation • algebraic expressions • infix notation • priority • parentheses • postfix notation aka Reverse Polish Notation (RPN) • Jan Lukasiewicz • no need for parentheses or operator priorities • operator follows operands • examples • evaluate left to right • hardware computation in ALU

  8. Infix to Postfix Translation • manual process • insert all parentheses • convert each sub-expression from inside out • remove parentheses • automated process? • desire single left to right pass over input • properties • operands in same order • operator after operands • save operator • cannot output operator until see next one • if saved is higher priority output else save next operator • at end must output saved operators in LIFO order • use a stack

  9. Rail Yard Algorithm • operands output as seen • for operator • lower/equal priority than one on stack output stacked op • higher priority than one on stack push input op • when done • emit stacked operators • special cases • no operator on stack  push • have low priority operator ($) at bottom of stack • end of expression  pop • have low priority operator (#) at end of expression

  10. Example: InfToPost • client of CharStack • translate method • initialization • create stack (ConCharStack or LnkCharStack) • String as char array • append # • push $ • main loop • process 1 character from input at a time • operand  output • operator  output some stacked operators then push • operator priorities • relative • prio method • # & $

  11. Generics

  12. Generic ADTs • behaviour of stack independent of type of item • generalize interface to allow any item type • generic Stack interface • based on hypothetical content type E • generalization (abstraction) over the content type • changes from CharStack • change from char to E throughout • addition of generic parameter <E> after interface name • E is a type variable • Collections package • set of collection ADTs (stack, queue, list, …) • common names for exceptions

  13. Parametric Types • Stack is a parametric type • varies depending on the type name provided as actual type parameter • with Stack<Character> opstack; as if E was replaced by Character Stack<Student> stdStack; as if E was replaced by Student • only need one interface to define both kinds of stacks • class and interface declaration syntax • scope of type_variable is the class or interface • type syntax • type_variable can be used wherever a reference_type used • type_argument supplied for each type_parameter in generic • type_argument must be a reference type (e.g. Character)

  14. Generic Implementation Classes • e.g. ConStack • compared to ConCharStack • E substituted for char throughout • ConStack is a parametric type • implements Stack with same type parameter • with opStack = new ConStack<Character>(8); • have a stack of Character using the ConStack implementation stdStack= new ConStack<Student>(10); • have a stack of Student using the ConStack implementation

  15. Type Compatibility • implements clause declares that the type_argument for Stack is whatever is supplied as type_argument for ConStack • thus ConStack<Character> implements Stack<Character> and ConStack<Student> implements Stack<Student> • and so in Stack<Character> opStack; opStack = new ConStack<Character>(); is valid opStack = new ConStack<Student>(); is invalid

  16. Type Checking • how does the compiler type check within generic class, e.g. elts[top] = item; • with ConStack<Character>, Character is substituted for E so this is OK • how does compiler know? • type_argument must be a reference_type • all reference_types are subtypes of Object • compiler type checks assuming type_variable is Object • thus the only operations available on the type_variable are those available on Object • note: compiler can still create the elts array since it knows it is an array of some reference type and thus each element is a reference (4 bytes)

  17. Implementation • consecutive implementation • note that in the constructor: elts = (E[]) new Object[size]; is used instead of the expected elts = new E[size]; • Java does not allow a type_parameter to be used in an array creation expression • creating an array of Object and downcasting it to E[] achieves the desired effect (unchecked cast warning) • garbage collection in pop • linked implementation • the generic Node class • in the linked version, the Node class must also be parametric since the type of the content is unknown • creation of a new Node is done via top = new Node<E>(item,top);

  18. Example: InfToPost Revisited • version of InfToPost using generic Stack • stack declared via: Stack<Character> opstack; • stack created using: opstack = new ConStack<Character>(8); • character pushed using opstack.push(c); • note c is of type char but push has parameter type ECharacter • Java automatically wraps c in a Character wrapper to provide type compatibility • this is an autoboxing conversion as if the statement was opstack.push(new Character(c));

  19. character popped using postfix[oPos] = opStack.pop(); • note that pop returns type ECharacter while postfix is type char[] • Java automatically unwraps the char from the Character object to provide type compatibility • this is an autounboxing conversion as if the statement was postfix[oPos] = opStack.pop().charValue();

  20. Java Collections Framework • Java library for data structure ADTs • java.util • stacks, queues, lists, sets, maps • Collection interface • generic in element type • operations common to all collections (except maps) • methods return boolean if the operation changed the collection (i.e. added or removed) • Stack class • generic in element type (E) • array implementation (Vector) grows to fit (no overflow) • some duplication of methods (legacy implementation) • push returns item pushed

More Related