Que problema não pode ser resolvido por um programa curto?

7

FUNDO:

Recentemente, tentei resolver um problema difícil que obtém como entrada uma matriz de números. Para , a única solução que encontrei foi ter um tratamento diferente para cada uma das ordenações dos 3 números. Ou seja, existe uma solução para o caso , outra solução para , etc. (o caso pode ser resolvido por qualquer uma dessas duas soluções).nn=3n!=6A>B>CA>C>BA>C=B

Pensando no caso , parece que a única maneira é, novamente, considerar todos os pedidos diferentes e desenvolver uma solução diferente para cada caso. Embora a solução em cada caso específico seja rápida, o próprio programa seria muito grande. Portanto, a complexidade do tempo de execução do problema é pequena, mas a complexidade do "tempo de desenvolvimento" ou da complexidade do "tamanho do programa" é muito grande.n=4n!=24

Isso me levou a tentar provar que meu problema não pode ser resolvido por um curto programa. Então, procurei referências para provas semelhantes.

O primeiro conceito que encontrei é a complexidade de Kolmogorov ; no entanto, as informações que encontrei sobre esse tópico são muito gerais e incluem principalmente resultados de existência.

QUESTÃO:

Você pode descrever um problema específico da vida real , de modo que qualquer programa que resolva em uma matriz de tamanho deve ter pelo menos , em que é uma função crescente de ?PPnΩ(f(n))f(n)n

Como a resposta obviamente depende da seleção da linguagem de programação, suponha que programamos em Java ou em uma máquina de Turing - o que for mais confortável para você.

Todo problema indecidível satisfaz trivialmente esse requisito porque não tem solução. Então, eu estou procurando uma linguagem decidível.

Erel Segal-Halevi
fonte
"algorítmico específico" "sequência específica do algoritmo"?
Você pode ser mais explícito em relação à sua última frase em relação à resposta trivial com qualquer problema indecidível. Eu tenho uma interpretação disso, mas não acho convincente.
21414
Você precisa começar de novo procurando uma solução para cada valor de n, raciocinando do zero? Ou existe um método para chegar ao programa certo, quando n é conhecido? Não entendo o que você quer dizer com complexidade do tempo de desenvolvimento ... isso depende da sua criatividade?
babou
@babou: Se houver um problema Pé indecidível, então não solução de programaP. Portanto, qualquer coisa que você diga sobre "qualquer solução de programaP"É verdade, porque não há nada para contradizê-lo Tudo o que você diz sobre os elementos de um conjunto vazio, é trivialmente verdadeira..
Erel Segal-Halevi
@babou: quero dizer que para cada valor de nvocê tem que pensar em uma solução do zero.
Erel Segal-Halevi 21/10

Respostas:

2

Suponho que o que você realmente deseja é uma enumeração de problemas, de modo que os programas correspondentes formem uma sequência crescente de tamanho. Aqui está um exemplo dessa enumeração. No entanto, apenas provo que o tamanho aumenta além de qualquer limite, portanto, não está emO(1), que parecia ser o seu ponto principal. Eu poderia tentar melhor, mas estou imaginando o que nesta resposta pode não ser aceitável na sua opinião da pergunta.

Se bem entendi, você quer uma enumeração Pn de problemas que são todos decidíveis com um algoritmo An, de modo que não exista um procedimento de decisão uniforme para a união desses problemas, porque, se houvesse um, seria um programa curto quando n fica grande, ou seja, seria O(1(n)).

Isso implica que a enumeração Annão é computável. Se fosse computável, aquele seria capaz de calcular o algoritmoAn a partir do conhecimento de n, possuindo, assim, um procedimento uniforme para a união de todos os problemas na enumeração.

Portanto, podemos procurar apenas exemplos de modo que não haja enumeração computável An de algoritmos tais que An resolve Pn.

Antes de entrarmos nisso, precisamos definir o tamanho de um

Deixei Tn ser uma enumeração pelos números de Gödel nde máquinas de Turing. Essa enumeração de Gödel é computável. Então deixaPn seja o seguinte problema: se Tn pára em todas as entradas, Pn consiste em reconhecer o conjunto recursivo reconhecido por Tn, outro Pn consiste em reconhecer o conjunto vazio .

Como estamos procurando limites mais baixos no tamanho do algoritmo An que resolve Pn, temos que definir o tamanho de uma TM. Para uma TM, seu número de Gödel pode ser considerado como o tamanho da máquina, ou seja, o algoritmo correspondente. De fato, o número de estados e transições aumenta necessariamente comn, mesmo que apenas por causa do princípio do buraco do pombo, embora ele não seja necessariamente uniforme (e dependa de uma definição arbitrária de tamanho).

Então, para qualquer TM Tn que sempre param, notamos μ(n) o menor número Gôdel de uma TM Tμ(n) para que sempre pare e reconheça o mesmo conjunto recursivo que Tn. ConseqüentementeTμ(n) é a menor TM que realmente é um algoritmo para resolver Pn, ou seja, é An. E seTn pode não parar, então para An simplesmente usamos sempre um algoritmo correspondente a uma TM T o reconhece o conjunto , sempre o mesmo.

Cada problema Pn é decidível e Ané um procedimento de decisão. No entanto, a enumeraçãoAn não é computável, mas mostramos que é inevitável.

É fácil mostrar que, dadas as constantes C, há um n tal que o tamanho |An| do An é melhor que C. O motivo é simplesmente que o número de máquinas menores queC é finito, enquanto o número de conjuntos recursivos reconhecidos pelas TMs é infinito.

Portanto, este é um exemplo de um problema (mais precisamente uma enumeração de problemas) que não pode ser resolvido por um programa curto, ou seja, de modo que não exista um limite constante no comprimento das soluções para cada Pn.

Podemos sempre adicionar a cada problema Pn que requer qualquer solução para ler primeiro uma matriz de tamanho n, de modo a atender à restrição na pergunta. Mas há pouco sentido nisso.

babou
fonte
Obrigado. Isso realmente responde à pergunta. O que estou realmente procurando (mas não sei como perguntar corretamente) é um problema natural , um problema que ocorre na vida real, onde o tamanho do programa aumenta com o tamanho da entrada.
Erel Segal-Halevi
@ErelSegalHale Eu estava ciente desse aspecto da vida real, mas não sei o que o distinguiria de uma resposta da TM, dadas as propriedades peculiares do problema, como a enumerabilidade não computável das soluções. Se a enumeração do seu problema é natural, eu estava realmente imaginando como você pode provar que todas elas são decidíveis, a menos que tenham sido construídas para isso. A indecidibilidade é geralmente provada (em última análise) por contradição, mas a decidibilidade geralmente é provada de forma construtiva, o que equivale a fornecer o procedimento de decisão para todos, o que você não pode fazer, pois eles não são computáveis ​​enumeráveis.
babou 23/10/14
"Não sei o que o distinguiria de uma resposta da MT, dada a ... enumerabilidade não computável de soluções" - Esse é um bom ponto, obrigado.
Erel Segal-Halevi
7

Para qualquer problema, você pode criar uma linguagem de programação em que um programa para codificar a solução para esse problema seja um único caractere. (cf. HQ9 + ). A complexidade de Kolmogorov depende da linguagem. A resposta à sua pergunta sobre quais problemas causam uma explosão dependerá fortemente de qualquer "linguagem formal padrão" que você escolher.

Existem alguns resultados interessantes, no entanto. A codificação de cadeias geradas aleatoriamente sempre exigirá um custo proporcional ao tamanho da cadeia. O princípio do buraco de pombo nos diz que sempre haverá algumas funções, em qualquer linguagem fixa L, que não podem ser expressas em um espaço menor que uma enumeração completa de todos os casos. E o teorema do tamanho de Blum nos diz que, para um idioma total, sempre existem funções que você pode codificar maior que um fator de explosão escolhido arbitrariamente em comparação com a codificação da mesma função em um idioma completo de Turing.

dmbarbour
fonte
"∃ funções, em qualquer linguagem fixa L, que não possam ser expressas em um espaço menor que uma enumeração completa de todos os casos." Quais são todos os casos? Você tem uma referência na web?
21714
Quero dizer uma enumeração completa de pares (domínio, intervalo). Você pode construir essas funções, por exemplo, mapeamento de um conjunto fixo de cadeias aleatórias para outro conjunto fixo de cadeias aleatórias. Desculpe, não tenho uma referência para apontar.
Dmbarbour 21/10
Eu acho que você quer dizer uma enumeração Pn de tais problemas para que cada Pndeve ser tão grande quanto a enumeração dos pares n (domínio, intervalo) (isso está correto?). Pena que você não tem idéia para encontrar mais informações sobre isso.
babou
6

Um resultado dos estados de Shannon de que existe uma sequência de funções fn:{0,1}n{0,1} isso é para que o problema P(n) de computação fn(x) para x{0,1}n requer ao menos Θ(2nn) operações booleanas (isto é, a complexidade do circuito da computação fn(x) é pelo menos Θ(2nn))

Esse teorema não é tão difícil de obter, pois existem 2(2n) n- ara funções booleanas, enquanto o número de circuitos do tamanho especificado é estritamente menor.

zarathustra
fonte
OK, isso mostra a existência de um problema que requer um programa grande, mas estou procurando uma prova específica de que um determinado problema (conhecido) requer um programa grande.
Erel Segal-Halevi
11
Eu sabia que essa não era uma resposta realmente satisfatória. Eu acho que a complexidade do circuito é a que mais se aproxima do "comprimento do programa", pois o tamanho do circuito varia com o tamanho da entrada, como no seu post. Limites inferiores nesta área devem ser conhecidos por alguns problemas específicos, mas eu não sou especialista.
Zaratustra
11
Eu acho que o tamanho de um circuito é mais parecido com a complexidade da execução do programa do que com o tamanho do código do programa. Minha idéia é que cada portão seja usado apenas uma vez. É um tipo de lógica linear. Se você faz o mesmo em software, onde é possível fatorar chamando subprogramas várias vezes, você tem o mesmo resultado no tamanho do programa? CC @ErelSegalHalevi
babou