¿Qué significa un algoritmo más rápido en informática teórica?

18

Si hay un algoritmo que se ejecuta en el tiempo para algún problema A, y a alguien se le ocurre un algoritmo que se ejecuta en el tiempo, , donde , ¿se considera una mejora con respecto al algoritmo anterior? $O(f(n))$ $O(f(n)/g(n))$ $g(n) = o(f(n))$

¿Tiene sentido, en el contexto de la informática teórica, proponer un algoritmo de este tipo?

algorithms

— amor
fuente

44

Por "algoritmo más rápido", queremos decir "algoritmo asintóticamente más rápido".

— Yuval Filmus

@YuvalFilmus, ¿qué quieres decir con "asintóticamente"

— indefinido el

1

Corriendo en el tiempo .

o (f (n))

$o(f(n))$

— Yuval Filmus

26

No, un algoritmo que se ejecuta en el tiempo , donde , no se considera necesariamente una mejora. Por ejemplo, supongamos que y . Entonces es un límite de tiempo peor que . $O(f(n)/g(n))$ $g(n) = o(f(n))$ $f(n) = n$ $g(n) = 1/n$ $O(f(n)/g(n)) = O(n^2)$ $O(f(n)) = O(n)$

Para mejorar un algoritmo que se ejecuta en el tiempo , debe crear un algoritmo que se ejecute en el tiempo , es decir, en el tiempo para alguna función . $f(n)$ $o(f(n))$ $g(n)$ $g(n) = o(f(n))$

Si todo lo que sabe es que un algoritmo se ejecuta en el tiempo , entonces no está claro si un algoritmo que se ejecuta en el tiempo es una mejora, cualquiera que sea son. Esto se debe a que O grande es solo un límite superior en el tiempo de ejecución. En lugar de ello, es común considerar el tiempo en el peor caso, y estimar como un gran en lugar de sólo como un gran . $O(f(n))$ $O(g(n))$ $f(n),g(n)$ $\Theta$ $O$

— Yuval Filmus
fuente

21

Podría ser mejor tomar en su primer párrafo. Usar una función decreciente se siente un poco engañoso.

g (n) = 1

$g(n)=1$

— David Richerby el

1

@DavidRicherby: Tal vez un poco, pero OP nunca dijo que tenían un algoritmo ejecutándose en por lo que no se puede suponer la monotonicidad.

O (g (n))

$O(g(n))$

— Kevin

77

@Kevin Claro, pero el contexto es la informática y, en informática, la notación big-O generalmente se usa para funciones no decrecientes. Probablemente el autor de la pregunta estaba pensando en esos términos.

— David Richerby

11

Recuerde que Notación es para el análisis de cómo la tarea crece para diferentes tamaños de entrada y, específicamente, deja fuera factores multiplicativos, de orden inferior término, y constantes. $O(...)$

Suponga que tiene un algoritmo cuyo tiempo de ejecución real es (suponiendo que realmente pueda contar las instrucciones y conocer los tiempos exactos, etc., lo cual es una suposición enorme en los sistemas modernos). Luego, suponga que se le ocurre un nuevo algoritmo que resulta ser , pero el tiempo de ejecución real es . Suponga también que sabe que el software para usar este algoritmo nunca verá un tamaño de problema de . $O(n^2)$ $1n^2+2n+1$ $O(n)$ $1000n + 5000$ $n>10$

Entonces, ¿cuál elegirías: el algoritmo que tomará 15000 unidades de tiempo, o el algoritmo que solo tomará 121 unidades? Ahora, si su software evoluciona para manejar tamaños de problemas de , ¿cuál elegiría? ¿Qué harías si el tamaño de tu problema varía mucho? $O(n)$ $O(n^2)$ $n>100000$

— Twalberg
fuente

2

"nunca vería un tamaño de problema de n> 10" - entonces no

— usaríamos

55

@AnoE Números simples en aras de la discusión. La misma lógica se aplica si está analizando un tamaño de problema de 10 frente a 1e5 o si está analizando para 1e6 frente a 1e9.

— twalberg

1

@AnoE La mayoría de los programas de computadora no intentan manejar un tamaño de problema infinitamente creciente. Entonces habrá una compensación. Es por eso que big-O es para la informática teórica , y los conceptos se pueden aplicar para mejorar los programas reales.

— mbomb007

Exactamente, @ mbomb007. El título de la pregunta es "¿Qué significa un algoritmo más rápido en informática teórica ?" y tiene esto en el cuerpo: "¿Tiene sentido, en el contexto de la informática teórica ...".

— AnoE

@AnoE ¡Por experiencia, la notación O se usa cuando n <10 todo el tiempo! No es que sea una buena idea ... ¡pero es algo totalmente hecho!

— Cort Ammon - Restablece a Mónica el

5

En general, lo que eso significa es que, para cualquier tamaño de entrada que sea lo suficientemente grande, el peor tiempo de ejecución del algoritmo anterior es más lento que el nuevo. Eso es equivalente al formalismo , donde es la complejidad temporal del nuevo algoritmo la complejidad temporal del antiguo. $g(n) \in o\bigl(f\left(n\right)\bigr)$ $g$ $f$

Sin embargo, a veces los informáticos se preocupan por el rendimiento promedio de los casos. El ejemplo clásico es la ordenación rápida: el peor de los casos el tiempo de ejecución es mientras que sabemos que otros que se ejecutan en tiempo, pero es ampliamente utilizado en la práctica debido a su buen tiempo de funcionamiento en el caso promedio. Además, se puede ajustar para que se ejecute muy rápidamente en los casos que son más frecuentes en la naturaleza, como las matrices que se encuentran principalmente en el orden correcto. $\Theta(n^2)$ $\Theta(n \log n)$

Y a veces, incluso los informáticos teóricos usan "más rápido" de la misma manera que las personas normales. Por ejemplo, la mayoría de las implementaciones de las clases de cadenas tienen la optimización de cadenas cortas (también llamada optimización de cadenas pequeñas), aunque solo acelera las cosas para cadenas cortas y es pura sobrecarga para las más largas. A medida que el tamaño de entrada aumenta y aumenta, el tiempo de ejecución de una operación String con SSO será mayor en un término constante pequeño, por lo que según la definición que di en el primer párrafo, eliminar SSO de una clase String lo hace "más rápido ”. Sin embargo, en la práctica, la mayoría de las cadenas son pequeñas, por lo que SSO hace que la mayoría de los programas que las usan sean más rápidos, y la mayoría de los profesores de informática saben mejor que andar por ahí exigiendo que las personas solo hablen sobre órdenes de complejidad asintótica del tiempo.

— Davislor
fuente

1

No existe una definición unificada de lo que es un "algoritmo más rápido". No existe un órgano rector que decida si un algoritmo es más rápido que otro.

Para señalar por qué esto es así, me gustaría ofrecer dos escenarios diferentes que demuestren este concepto turbio.

El primer ejemplo es un algoritmo que busca en una lista vinculada de datos no ordenados. Si puedo hacer la misma operación con una matriz, no tengo ningún cambio en la gran medida de rendimiento de Oh. Ambas búsquedas son O (n). Si solo miro los grandes valores de Oh, podría decir que no hice ninguna mejora en absoluto. Sin embargo, se sabe que las búsquedas de matrices son más rápidas que recorrer una lista vinculada en la mayoría de los casos, por lo que uno puede decidir que eso hizo que un algoritmo sea "más rápido", a pesar de que el gran Oh no cambió.

Si puedo usar el ejemplo tradicional de programar un robot para hacer un sándwich PBJ, puedo mostrar lo que quiero decir de otra manera. Considere solo el punto donde uno está abriendo el frasco de mantequilla de maní.

Pick up the jar
Grab the lid
Unscrew the lid

Versus

Pick up the jar
Put the jar back down
Pick up the jar
Put the jar back down
Pick up the jar
Put the jar back down
Pick up the jar
Put the jar back down
Pick up the jar
Put the jar back down
Pick up the jar
Grab the lid
Unscrew the lid

Incluso en el entorno teórico más académico que se me ocurre, encontrará que las personas aceptan que el primer algoritmo es más rápido que el segundo, a pesar de que los grandes resultados de la notación Oh son los mismos.

Por el contrario, podemos considerar un algoritmo para romper el cifrado RSA. Por el momento, se percibe que este proceso es probablemente O (2 ^ n), donde n es el número de bits. Considere un nuevo algoritmo que se ejecuta n ^ 100 más rápido. Esto significa que mi nuevo proceso se ejecuta en O (2 ^ n / n ^ 100). Sin embargo, en el mundo de la criptografía, una aceleración polinómica a un algoritmo exponencial no se considera tradicionalmente como una aceleración teórica. Al hacer pruebas de seguridad, se supone que un atacante puede descubrir una de estas aceleraciones y que no tendrá ningún efecto.

Entonces, en una circunstancia, podemos cambiar un O (n) a O (n) y llamarlo más rápido. En una circunstancia diferente, podemos cambiar un O (2 ^ n) a O (2 ^ n / n ^ 100), y afirmar que no hubo una aceleración significativa en absoluto. Por eso digo que no hay una definición unificada para un "algoritmo más rápido". Siempre depende del contexto.

— Cort Ammon - Restablece a Monica
fuente

1

$A(n) \in O(f(n))$

\exists 0 0 \leq C_{F} < \infty ∣ \underset{norte \to \infty}{lim sup} \frac{UN (norte)}{F (norte)} = C_{F}

$\exists \ 0 \le c_f \lt \infty \mid \ \limsup_{n \to \infty} \frac{A(n)}{f(n)} = c_f$

$g(n)$ $\limsup_{n\to\infty} g(n) = \infty$ $h(n) = \frac{f(n)}{g(n)}$

$A'(n)$ $O(h(n))$ $A(n)$ $O(h(n))$

\exists 0 0 \leq C_{h} < \infty ∣ \underset{norte \to \infty}{lim sup} \frac{UN (norte)}{h (norte)} = C_{h}

$\exists \ 0 \le c_h \lt \infty \mid \ \limsup_{n \to \infty} \frac{A(n)}{h(n)} = c_h$

Usando las reglas de límites, también podemos escribir:

C_{h} = \underset{norte \to \infty}{lim sup} \frac{UN (norte)}{h (norte)} = \underset{norte \to \infty}{lim sup} \frac{UN (norte) sol (norte)}{F (norte)} = C_{F} \cdot \underset{norte \to \infty}{lim sup} sol (norte)

$c_h = \limsup_{n \to \infty} \frac{A(n)}{h(n)} = \limsup_{n \to \infty} \frac{A(n)g(n)}{f(n)} = c_f \cdot \limsup_{n \to \infty} g(n)$

$c_h \lt \infty$ $c_f = 0$

$c_f \neq 0$ $A(n) \notin O(h(n))$

$A'(n)$ $A(n)$ $A(n) \in \Theta(f(n))$ $g(n)$

$A(n) \in O(f(n))$ $A'(n)$ $A(n)$ $O(h(n))$

— Jared Goguen
fuente

1

Su límite debe ser límite superior.

— Yuval Filmus

1

@YuvalFilmus Actualizado

— Jared Goguen