análisis de tiempo de algoritmo "tamaño de entrada" vs "elementos de entrada"

Todavía estoy un poco confundido con los términos "longitud de entrada" y "tamaño de entrada" cuando se usan para analizar y describir el límite superior asintomático de un algoritmo

Parece que la longitud de entrada para el algoritmo depende mucho del tipo de datos y del algoritmo del que está hablando.

Algunos autores se refieren a la longitud de entrada al tamaño de los caracteres que se requieren para representar la entrada, por lo que "abcde" si se usa como conjunto de entrada en un algoritmo tendrá una "longitud de entrada" de 6 caracteres.

Si en lugar de caracteres tenemos números (enteros, por ejemplo), a veces se usa la representación binaria en lugar de caracteres, por lo que la "longitud de entrada" se calcula como (siendo L el número máximo en el conjunto de entrada). $N*log(L)$

Existen otros problemas que incluso si el conjunto de entrada son números, describen la "longitud de entrada" como "variables de decisión", por lo que para un conjunto de entrada de longitud N con números en el rango la longitud de entrada es solo N (suma de subconjuntos, por ejemplo), o incluso más complican la cantidad de valores de posición binarios que se necesitan para indicar el problema (lo que creo que es lo mismo que ) $0-2^{32}$ $N*log(L)$

Entonces:

Depende del algoritmo?
Qué significa y cuándo usar cada "versión" de longitud de entrada
¿Hay alguna regla que pueda usar para decidir cuál usar?

— Jesus Salas
fuente

En el sentido más formal, el tamaño de la entrada se mide en referencia a una implementación del algoritmo de la máquina de Turing, y es la cantidad de símbolos alfabéticos necesarios para codificar la entrada.

Esto es, por supuesto, bastante abstracto, y es muy difícil trabajar con él en la práctica, o al menos muy molesto. Necesitaríamos considerar cómo vamos a especificar delimitadores, etc., etc. Lo que sucede normalmente en la práctica es que buscamos una medición proxy del tamaño de la entrada, algo más conveniente y accesible, pero que no causa ningún problema matemático en nuestro análisis.

Usando su ejemplo "abcde", normalmente sería el caso de que el alfabeto que usamos para la entrada sea pequeño, por lo que incluso usando la medición proxy de caracteres, sabemos que incluso en una máquina de Turing, podemos, si nos molestamos, especifique una codificación de entrada que convierta "abcde" en alguna forma codificada que tenga una longitud máxima de para alguna constante . Esta expansión por una constante típicamente no haría ninguna diferencia en nuestro análisis asintótico, ya que descartamos habitualmente factores constantes. $5$ $5\times c$ $c$

En un caso diferente, a menudo medimos el tamaño de un gráfico de entrada por el número de vértices . Claramente, si queremos especificar gráficos arbitrariamente grandes, el tamaño de la entrada codificada no es simplemente , ¿qué pasó con los bordes, por ejemplo? Lo que sí sabemos es que podemos usar un esquema de codificación razonable que represente el gráfico en bits. Esto es un poco más una expansión que una constante, pero en muchos casos interesantes, solo estamos tratando con una granularidad de polinomios, y los polinomios se componen muy bien de muchas maneras, en particular, por ejemplo, si determinamos que nuestro tiempo de ejecución es $n$ $n$ $N = c\cdot n^{2}\log n$ donde es un polinomio, entonces sabemos que hay algún polinomio tal que , entonces cuando volvemos a la medida formal de la entrada , todavía estamos en tiempo polinómico. $O(p(n))$ $p$ $p'$ $O(p(n)) = O(p'(N))$

Un lugar donde esto podría caerse es cuando trabajas con números. Como un número con magnitud puede codificarse en bits, si nuestro tiempo de ejecución fuera , esto sería - exponencial en el tamaño de entrada real - lo que haría que la magnitud una mala elección para un proxy para el tamaño de entrada si quisiéramos hablar sobre la membresía en por ejemplo (cuando se trata de Strongly- -complete y Weakly- $m$ $n = O(\log m)$ $O(m)$ $O(2^{n})$ $m$ $\mathcal{P}$ $\mathcal{NP}$ $\mathcal{NP}$ -completo, recuerda esto). Por otro lado, si todo lo que nos interesara fuera la capacidad de decisión, entonces sería una medida proxy bastante buena.

Entonces, aunque no hay una regla establecida para elegir una medida de proxy para el tamaño de entrada, el requisito es que la expansión o contracción del tamaño de proxy en comparación con el tamaño de entrada debe ser compatible con lo que está tratando de probar. Como regla general, los cambios constantes en los factores casi nunca importan, los pequeños factores polinomiales normalmente están bien y funcionan para la mayoría de la teoría básica que ves, los factores polinomiales grandes aún pueden funcionar para la teoría, pero pueden ser una desagradable sorpresa en la práctica, y las cantidades exponenciales de cambio son normalmente demasiado extremas.

— Luke Mathieson
fuente

Gracias por la respuesta. Realmente interesante la parte que habla sobre la selección del proxy correcto para hablar sobre la membresía en P o NP para la entrada, ¡esa podría ser una pregunta completamente nueva! Además de eso, y volviendo a la pregunta anterior. ¿Cuál, en su opinión, sería el mejor proxy para un algoritmo que su entrada es un conjunto de enteros? Supongo que tal vez dependerá del algoritmo? Veo 3 opciones potenciales: N (que es la longitud del conjunto) N * Log (L) (L es el valor máximo) y Log (Sum (set)).

— Jesús Salas

@JesusSalas, definitivamente puede depender de lo que hagas con ellos, pero

sería la respuesta más simple "lo suficientemente cerca de la codificación TM", pero aún puede ser interesante observar el tiempo de ejecución en términos de

, o tal vez

y la magnitud del mayor número; por supuesto, esto es solo

, pero a veces puede ser más fácil analizar cosas con medidas no obvias.

N \log L

$N\log L$

N

$N$

N

$N$

2^{\log L}

$2^{\log L}$

— Luke Mathieson

Esto cubre las bases pero hay algunas imprecisiones. Representar "abcde" en una máquina de Turing no toma

caracteres

: toma cinco caracteres si elige el alfabeto correcto. Y no necesita

bits para representar un gráfico

-vertex: la matriz de adyacencia es exactamente

bits.

5 c

$5c$

c n^{2} \log n

$cn^2\log n$

n

$n$

n^{2}

$n^2$

— David Richerby

Quizás cuándo usar N o N log L podría depender del costo para que el algoritmo funcione en cada elemento de entrada. Supongo que si asumimos que el algoritmo usa tiempo constante para hacer su trabajo en cada elemento de entrada independientemente de su tamaño en bits (y esto no se abusa), entonces N es probablemente el correcto, lo que resulta en O (N) . Por otro lado, si el tamaño del elemento de entrada en bits aumenta el costo de operación, entonces N log L parece más preciso ya que deberíamos expresar en el límite superior qué propiedades de la entrada están involucradas en el crecimiento

— Jesus Salas

5

$5$

c = 1

$c=1$

c = \log_{2} 5

$c = \log_{2}5$

5

$5$

O (n^{2} \log n)

$O(n^{2}\log n)$ bits, pero es un límite superior bastante robusto que puede manejar ambas codificaciones normales.

— Luke Mathieson

Depende de su modelo de cálculo y también, lamentablemente, a veces del algoritmo mismo.

$ababcd$
Si su modelo es la RAM, entonces el tamaño de la entrada es el número de registros / celdas de memoria donde inicialmente permanece la entrada. Esto podría ser mal utilizado, ya que técnicamente podría escribir toda la entrada en un registro. Sin embargo, los cálculos son más costosos si utiliza el modelo de costos logarítmicos.
$w$ $w$

Sin embargo, muchos algoritmos no se miden con respecto al tamaño de entrada "real". Luego, debe observar cuidadosamente a qué se refiere la declaración del análisis.

$O(n\log n)$ $n$ $O(1)$ $n$
$n\times n$

$n$

— A.Schulz
fuente

n

$n$

O (n^{3})

$O(n^3)$

n

$n$

n

$n$