A diferença entre complexidade teórica e eficiência prática

Se eu tiver esse pseudocódigo:

for i=0 to n/2 do
   for j=0 to n/2 do 
       ... do anything ....

O número de iterações é $n^2/4$.

Qual é a complexidade deste programa? É isso$O(n^2)$?

Qual é a intuição formal / informal para qual é essa complexidade?

Em seguida, se eu tiver esse outro pseudocódigo:

for i=0 to n do
   for j=0 to n do 
       ... do anything ....

A complexidade é novamente $O(n^2)$ - isso está correto?

Existe alguma diferença entre eficiência na prática e complexidade teórica neste caso? Um deles é mais rápido que o outro?

Big O Formalmente

$O(f(n)) = \{g(n) | \exists c > 0, \exists n_0 > 0, \forall n > n_0 : 0 \leq g(n) \leq c*f(n)\}$

Big O Informally

$O(f(n))$ é o conjunto de funções que crescem mais lentamente (ou igualmente rápido) do que $f(n)$. Isso significa que qualquer função que você escolher$O(f(n))$vamos chamá-la $g(n)$e você escolhe um tamanho suficientemente grande $n$, $f(n)$ será maior que$g(n)$. Ou, em outras palavras,$f(n)$ acabará por superar qualquer função em $O(f(n))$ quando $n$ cresce maior. $n$ é o tamanho da entrada do seu algoritmo.

Como um exemplo. Vamos escolher$f(n) = n^2$.

Nós podemos dizer que $f(n) \in O(n^3)$. Observe que, com o tempo, permitimos abuso de notação para que quase todo mundo escreva$f(n) = O(n^3)$ agora.

Normalmente, quando avaliamos algoritmos, observamos a ordem deles. Dessa forma, podemos prever como o tempo de execução do algoritmo aumentará quando o tamanho da entrada ($n$) aumenta.

No seu exemplo, os dois algoritmos são de ordem $O(n^2)$. Portanto, o tempo de execução aumentará da mesma maneira (quadraticamente) que$n$aumenta. Seu segundo algoritmo será quatro vezes mais lento que o primeiro, mas isso é algo em que geralmente não estamos interessados ​​** teoricamente *. Algoritmos com a mesma ordem podem ter fatores diferentes ($c$na definição formal) ou em diferentes termos de ordem inferior na função que avalia o número de etapas. Mas geralmente é por causa dos detalhes da implementação e não estamos interessados ​​nisso.

Se você tiver um algoritmo executado em $O(log(n))$ tempo, podemos dizer com segurança que será mais rápido do que $O(n)$ [1] porque $log(n) = O(n)$. Não importa o quão ruim o$O(log(n))$ algoritmo é implementado, não importa quanto sobrecarga você coloque no algoritmo, ele sempre será [1] mais rápido que o $O(n)$algoritmo. Mesmo que o número de etapas nos algoritmos seja$9999*log(n) = O(log(n))$ e $0.0001*n = O(n)$, a $O(log(n))$ o algoritmo será eventualmente mais rápido [1].

Mas, talvez, na sua aplicação, $n$ é sempre baixo e nunca será suficientemente grande para que o $O(log(n))$algoritmo será mais rápido na prática . Então, usando o$O(n)$ algoritmo resultará em tempos de execução mais rápidos, apesar de $n = O(log(n))$

[1] se $n$ é suficientemente grande.

Auberon forneceu uma explicação muito boa do Big O . Vou tentar explicar o que isso significa para você.

Primeiro de você está certo. O primeiro exemplo de código possui$\frac{n^2}{4}$iterações, mas ainda está na classe de complexidade O(n^2).

Por quê?

A coisa sobre classes de complexidade é que nós assumimos que fazer algo várias vezes não é que ruim para a execução.

Imagine um algoritmo com complexidade em O(2^n)execução por n=31 segundo.

Poderíamos executar isso 10 vezes e ainda esperar uma resposta após cerca de 10 segundos.

Agora imagine aumentar n10. O programa levará 2^10=1024segundos.

Então, os cientistas da computação basicamente disseram: " Cara, os principais fatores são irritantes. Vamos apenas assumir que n cresce até o infinito e comparar funções lá "

Que levam à Big O .

Na prática

Na prática, é muito bem possível que uma solução com muito pior complexidade seja executada muito mais rapidamente (para entradas "pequenas"). É fácil imaginar um programa que é executado, O(n)mas precisa de 10^10*niterações.

É O (n), mas mesmo uma O(2^n)solução poderia ser mais rápida para n pequeno.

Em suma:

O Big O é uma ferramenta útil. Mas você ainda precisa pensar na rapidez com que o algoritmo está em prática, pois ele descreve apenas quanto mais tempo será necessário se a entrada aumentar.

Se eu tiver esse pseudocódigo:

for i=0 to n/2 do
   for j=0 to n/2 do 
       ... do anything ....

O número de iteração é $n^2/4$.

Na verdade, é $(1+n/2)^2 = n^2/4 + n + 1$.

Qual é a complexidade deste programa? Está correto$O(n^2)$?

Isso depende inteiramente do que é "fazer qualquer coisa". Por exemplo, se "fazer qualquer coisa" for substituído pela linha

for k=0 to 2^n do {}

então o tempo de execução é $\Theta(n^22^n)$.