Big O, what is the complexity of summing a series of n numbers?

Question

I always thought the complexity of:

1 + 2 + 3 + ... + n is O(n), and summing two n by n matrices would be O(n^2).

But today I read from a textbook, "by the formula for the sum of the first n integers, this is n(n+1)/2" and then thus: (1/2)n^2 + (1/2)n, and thus O(n^2).

What am I missing here?

Solution 1

The big O notation can be used to determine the growth rate of any function.

In this case, it seems the book is not talking about the time complexity of computing the value, but about the value itself. And n(n+1)/2 is O(n^2).

Solution 2

You are confusing complexity of runtime and the size (complexity) of the result.

The running time of summing, one after the other, the first n consecutive numbers is indeed O(n).¹

But the complexity of the result, that is the size of “sum from 1 to n” = n(n – 1) / 2 is O(n ^ 2).

---

¹ But for arbitrarily large numbers this is simplistic since adding large numbers takes longer than adding small numbers. For a precise runtime analysis, you indeed have to consider the size of the result. However, this isn’t usually relevant in programming, nor even in purely theoretical computer science. In both domains, summing numbers is usually considered an O(1) operation unless explicitly required otherwise by the domain (i.e. when implementing an operation for a bignum library).

Solution 3

n(n+1)/2 is the quick way to sum a consecutive sequence of N integers (starting from 1). I think you're confusing an algorithm with big-oh notation!

If you thought of it as a function, then the big-oh complexity of this function is O(1):

public int sum_of_first_n_integers(int n) {
  return (n * (n+1))/2;
}

The naive implementation would have big-oh complexity of O(n).

public int sum_of_first_n_integers(int n) {
  int sum = 0;
  for (int i = 1; i <= n; i++) {
    sum += n;
  }
  return sum;
}

Even just looking at each cell of a single n-by-n matrix is O(n^2), since the matrix has n^2 cells.

Solution 4

There really isn't a complexity of a problem, but rather a complexity of an algorithm.

In your case, if you choose to iterate through all the numbers, the the complexity is, indeed, O(n).

But that's not the most efficient algorithm. A more efficient one is to apply the formula - n*(n+1)/2, which is constant, and thus the complexity is O(1).

Solution 5

So my guess is that this is actually a reference to Cracking the Coding Interview, which has this paragraph on a StringBuffer implementation:

On each concatenation, a new copy of the string is created, and the two strings are copied over, character by character. The first iteration requires us to copy x characters. The second iteration requires copying 2x characters. The third iteration requires 3x, and so on. The total time therefore is O(x + 2x + ... + nx). This reduces to O(xn²). (Why isn't it O(xnⁿ)? Because 1 + 2 + ... n equals n(n+1)/2 or, O(n²).)

For whatever reason I found this a little confusing on my first read-through, too. The important bit to see is that n is multiplying n, or in other words that n² is happening, and that dominates. This is why ultimately O(xn²) is just O(n²) -- the x is sort of a red herring.

View more solutions