analyzing the array-based stack implementation table shows the running times for our arraystack methods the analysis directly mirrors the analysis of the list class given in section the implementations for topis emptyand len use constant time in the worst case the ( time for push and pop are amortized bounds (see section ) typical call to either of these methods uses constant timebut there is occasionally an ( )-time worst casewhere is the current number of elements in the stackwhen an operation causes the list to resize its internal array the space usage for stack is (noperation push(es pops tops is emptylen(samortized running time ( ) ( ) ( ( ( table performance of our array-based stack implementation the bounds for push and pop are amortized due to similar bounds for the list class the space usage is ( )where is the current number of elements in the stack avoiding amortization by reserving capacity in some contextsthere may be additional knowledge that suggests maximum size that stack will reach our implementation of arraystack from code fragment begins with an empty list and expands as needed in the analysis of lists from section we emphasized that it is more efficient in practice to construct list with initial length than it is to start with an empty list and append items (even though both approaches run in (ntimeas an alternate model for stackwe might wish for the constructor to accept parameter specifying the maximum capacity of stack and to initialize the data member to list of that length implementing such model requires significant changes relative to code fragment the size of the stack would no longer be synonymous with the length of the listand pushes and pops of the stack would not require changing the length of the list insteadwe suggest maintaining separate integer as an instance variable that denotes the current number of elements in the stack details of such an implementation are left as exercise -