This falls under "a software algorithm" from stackoverflow.com/help/on-topic, in this case, a software algorithm to add an item to a dynamic unsorted array

This is chart we made in class about the runtimes of operations on different data structures ![enter image description here][1]

The question I have is about the runtime for inserting(or adding) a value into the dynamic unsorted array. Here is our code for doing this

 public void insert(E value) {
    ensureCapacity(size + 1);
    elementData[size] = value;
    size++;
}
  private void ensureCapacity(int capacity) {
    if (capacity > elementData.length) {
        int newCapacity = elementData.length + 100;
        if (capacity > newCapacity) {
            newCapacity = capacity;
        }
        elementData = Arrays.copyOf(elementData, newCapacity);
    }
}

I understand how this could be interpreted as O(n). The ensureCapacity function is technically apart of the operations that consist of insert and then with runtime analysis, https://academics.tjhsst.edu/compsci/CS2C/U2/bigoh.html, you would say that the worst case of the two branches is when every element of the original array is copied into the new array which is an O(n) operation. So the worst case or big oh of the whole function is O(n)

Could an argument be made for amortized O(1) time as well(What is amortized analysis of algorithms?) because each time you resize, you have to wait a specific amount of time before the next resize?

In that chart, would O(1) also make sense then? [1]: https://i.sstatic.net/n0Ykj.png

This falls under "a software algorithm" from stackoverflow.com/help/on-topic, in this case, a software algorithm to add an item to a dynamic unsorted array

This is chart we made in class about the runtimes of operations on different data structures

The question I have is about the runtime for inserting(or adding) a value into the dynamic unsorted array. Here is our code for doing this

 public void insert(E value) {
    ensureCapacity(size + 1);
    elementData[size] = value;
    size++;
}
  private void ensureCapacity(int capacity) {
    if (capacity > elementData.length) {
        int newCapacity = elementData.length + 100;
        if (capacity > newCapacity) {
            newCapacity = capacity;
        }
        elementData = Arrays.copyOf(elementData, newCapacity);
    }
}

I understand how this could be interpreted as O(n). The ensureCapacity function is technically apart of the operations that consist of insert and then with runtime analysis, https://academics.tjhsst.edu/compsci/CS2C/U2/bigoh.html, you would say that the worst case of the two branches is when every element of the original array is copied into the new array which is an O(n) operation. So the worst case or big oh of the whole function is O(n)

Could an argument be made for amortized O(1) time as well(What is amortized analysis of algorithms?) because each time you resize, you have to wait a specific amount of time before the next resize?

In that chart, would O(1) also make sense then?

This falls under "a software algorithm" from stackoverflow.com/help/on-topic, in this case, a software algorithm to add an item to a dynamic unsorted array

This is chart we made in class about the runtimes of operations on different data structures ![enter image description here][1]

The question I have is about the runtime for inserting(or adding) a value into the dynamic unsorted array. Here is our code for doing this

 public void insert(E value) {
    ensureCapacity(size + 1);
    elementData[size] = value;
    size++;
}
  private void ensureCapacity(int capacity) {
    if (capacity > elementData.length) {
        int newCapacity = elementData.length + 100;
        if (capacity > newCapacity) {
            newCapacity = capacity;
        }
        elementData = Arrays.copyOf(elementData, newCapacity);
    }
}

I understand how this could be interpreted as O(n). The ensureCapacity function is technically apart of the operations that consist of insert and then with runtime analysis, https://academics.tjhsst.edu/compsci/CS2C/U2/bigoh.html, you would say that the worst case of the two branches is when every element of the original array is copied into the new array which is an O(n) operation. So the worst case or big oh of the whole function is O(n)

Could an argument be made for amortized O(1) time as well(What is amortized analysis of algorithms?) because each time you resize, you have to wait a specific amount of time before the next resize?

In that chart, would O(1) also make sense then? [1]: https://i.sstatic.net/n0Ykj.png

This falls under "a software algorithm" from stackoverflow.com/help/on-topic, in this case, a software algorithm to add an item to a dynamic unsorted array

This is chart we made in class about the runtimes of operations on different data structures ![enter image description here][1]

The question I have is about the runtime for inserting(or adding) a value into the dynamic unsorted array. Here is our code for doing this

 public void insert(E value) {
    ensureCapacity(size + 1);
    elementData[size] = value;
    size++;
}
  private void ensureCapacity(int capacity) {
    if (capacity > elementData.length) {
        int newCapacity = elementData.length + 100;
        if (capacity > newCapacity) {
            newCapacity = capacity;
        }
        elementData = Arrays.copyOf(elementData, newCapacity);
    }
}

I understand how this could be interpreted as O(n). The ensureCapacity function is technically apart of the operations that consist of insert and then with runtime analysis, https://academics.tjhsst.edu/compsci/CS2C/U2/bigoh.html, you would say that the worst case of the two branches is when every element of the original array is copied into the new array which is an O(n) operation. So the worst case or big oh of the whole function is O(n)

Could an argument be made for amortized O(1) time as well(What is amortized analysis of algorithms?) because each time you resize, you have to wait a specific amount of time before the next resize?

In that chart, would O(1) also make sense then? [1]: https://i.sstatic.net/n0Ykj.png