Dado el interés en esta pregunta, pensé que podría ser útil señalar más explícitamente la razón por la que no deberíamos sorprendernos en absoluto con la respuesta e intentar dar alguna dirección para los refinamientos de la pregunta. Esto recopila y amplía algunos comentarios. Pido disculpas si esto es "obvio"!
Considere el conjunto de cadenas de complejidad de Kolmogorov :
Hay como máximo tales cadenas, ya que hay descripciones de longitud . Pero tenga en cuenta que este conjunto es indecidible para general (de lo contrario, podríamos calcular simplemente iterando de a y comprobando la pertenencia a ). Además, la función
Crece indiscutiblemente rápido. Es una variante de la función de castor ocupado: ¿cuál es la salida más larga de una máquina Turing de longitud descriptivaJ K ( n ) = { w : K ( w ) = n } . 2 n 2 n n n K ( w ) n = 1 | w | J K ( n ) g K ( n ) = max w ∈ J K ( n ) | w | n M M ′ Mn
JK(n)={w:K(w)=n}.
2n2nnnK(w)n=1|w|JK(n)gK(n)=maxw∈JK(n)|w|
n? Si esto se hizo más lento que alguna función computable, podríamos decidir el problema de detención: dada una TM , construya que simule e imprima un en cada paso. Si la longitud de la descripción de es , entonces: detiene a lo sumo pasos; o no se detiene.
MM′MM ′ n M g K ( n ) M1M′nMgK(n)M
Ahora, a la pregunta de Andrew, tenemos que , donde es el lenguaje original. Entonces, la única forma de evitar que contenga entradas muy grandes en sería si contiene solo cadenas muy incompresibles. (Tenga en cuenta que, de lo contrario, podemos ignorar por completo la distinción entre el análisis del caso más desfavorable y el caso medio, porque promediamos como máximo cadenas pero el tamaño de la cadena más grande está creciendo más rápido que cualquier función computable de . )S I K ( n ) n S 2 n nIK(n)=S∩JK(n)SIK(n)nS2nn
Creo que es probable que sea imposible construir cualquier no trivial (es decir, infinita) que contenga solo cadenas no comprimibles, pero que sea decidible. Pero no lo se. Sin embargo, es de esperar que esto dé una intuición de por qué no deberíamos esperar que la mayoría de los idiomas tengan creciendo más lentamente que una función computable.f K nSfKn
Para retroceder un poco, la pregunta es comparar el rendimiento en las entradas de longitud con el rendimiento en las entradas que se pueden comprimir a la longitud . Pero tenemos nociones de compresión que son mucho más manejables (y menos potentes) que la complejidad de Kolmogorov. Una manera simple es dar un circuito de tamaño , que en la entrada el número binario produce el bit de . Tenga en cuenta que aquí el aumento en el tamaño de entrada es como máximo exponencial (un circuito de tamaño tiene como máximo entradas posibles).n n b b w n 2 nnnnbbwn2n
Entonces podemos reformular la pregunta dejando
Y defina análoga. La razón de la esperanza aquí es que la mayoría de las cadenas requieren un circuito casi tan grande como la cadena misma, y ninguna cadena es más que exponencialmente más grande que el circuito requerido. Quizás en este caso podríamos encontrar lenguajes donde y son similares asintóticamente.
IC(n)={w∈S:the smallest circuit implicitly specifying w has size n}.
fCnfnfCn
Una pregunta muy relacionada es la complejidad de los lenguajes implícitos como
IMPLICIT_SAT es NEXP-complete y, por lo general, la versión implícita de los problemas de NP-complete es NEXP-complete. Decidir IMPLICIT_SAT es al menos tan fácil como usar el circuito para escribir todo y luego ejecutar un algoritmo para SAT en . Entonces, si para SAT, entonces esto parece cercano a dar evidencia de que IMPLICIT_SAT en el caso promedio es casi tan rápidamente decidible como SAT en el peor de los casos. Pero no sé cómo se podría comparar directamente su noción con los lenguajes implícitos porque la noción de "circuito más pequeño paraw w f C n = Θ ( f n ) w
IMPLICIT_SAT={circuits C:C implicitly specifies w,w∈SAT}.
wwfCn=Θ(fn)w"no entra en juego para lenguajes implícitos.
Espero que esto sea útil / interesante!
No estoy seguro de un libro de texto que mencione problemas implícitos, pero aquí hay algunas notas de la conferencia: http://people.seas.harvard.edu/~salil/cs221/spring10/lec8.pdf