Qual é um exemplo de um problema de negócios computacionalmente impossível?

Tenho um colega de trabalho que se recusa a aceitar a realidade de que as máquinas de Turing (e as máquinas de Von Neuman por extensão) não podem resolver seu próprio problema de parada, afirmando:

Você pode fazer qualquer coisa com tempo e dinheiro suficientes.

Ele também não gosta de problemas teóricos, argumentando que:

Em nosso campo, nunca encontraremos essas perguntas. Somos desenvolvedores de aplicativos, não cientistas teóricos.

Existe um bom exemplo de um problema comercial que é computacionalmente impossível que eu poderia usar para ajudar a convencê-lo disso?

Não é tecnicamente impossível, mas ...

Recursos de agendamento , com o objetivo de encontrar o agendamento ideal que maximize o uso de horários. Eu estava em um projeto uma vez, nos meus dias anteriores de computação, que tinha esse requisito. Eu trabalhei nisso por um tempo antes de perceber que era difícil para o NP.

Outros exemplos de problemas que não são tecnicamente impossíveis, mas são tecnicamente difíceis, podem ser encontrados aqui .

A maioria dos problemas computacionais difíceis em computação comercial não é impossível, apenas impraticável. Seu amigo está certo; você pode resolver a maioria deles se jogar dinheiro suficiente neles. Mas o argumento é ilusório; o objetivo de administrar um negócio é ganhar dinheiro, não perdê-lo.

Na prática diária, falamos sobre a integridade de Turing de maneira vaga, não para demonstrar algum princípio matemático, mas para ilustrar (por exemplo) a inadequação do HTML e CSS como um veículo completo para a produção de programas com recursos completos.

Da mesma forma, o Problema da Parada é importante para os teóricos, mas não tem muita relevância para a maioria das empresas.

Outros comentaram sobre isso, mas tentarei escrever uma resposta que dê meu ponto de vista.

Gosto da resposta de Robert Harvey e dos comentários à sua resposta, e gostaria de expandir sobre eles.

Eu acho que você precisa apresentar esses problemas indecidíveis (como rescisão) de uma maneira mundana: por exemplo, uma ferramenta IDE que "verifica se essa função sempre retorna um valor".

Ao ensinar, meu exemplo favorito era refatoração ( equivalência de função, outro problema indecidível ). Eu perguntei:

como você verifica se uma função / programa faz o mesmo após sua boa refatoração? Claro, temos testes de unidade para isso, mas eles não cobrem todos os casos. E eles são chatos de escrever ... Mas nós somos programadores! Deveríamos escrever um programa que verifique se essas duas funções estão sempre produzindo o mesmo resultado! Por que você não tenta escrever?

ou, como uma variação talvez mais próxima do seu caso:

Temos esse código legado escrito em um dialeto COBOL obscuro antigo, para o qual não existem especificações e / ou compiladores. Nós só temos o programa. Todo o nosso negócio depende disso, por isso temos que ter 100% de certeza de que o novo código Java faz exatamente o mesmo em todas as situações. A gerência quer um programa que faça isso, verificando todos os casos possíveis e estima que isso pode ser feito em 6 a 8 semanas. Por que você não tenta escrever?

O objetivo não é escrever esse programa. Ou uma aproximação suficientemente boa dos requisitos. O objetivo é perceber que NÃO pode ser feito de maneira direta, NÃO desperdice incontáveis ​​nossas tentando descobrir como fazê-lo (apenas para perceber que não é possível), mas reconhecê-lo. "Ah! Isso é indecidível! Não é possível fazê-lo diretamente. Preciso descobrir uma maneira diferente e mais inteligente de fazê-lo, com uma aproximação suficientemente boa".

Você precisa descobrir uma maneira de apresentar o problema de uma maneira reconhecível e aparentemente simples. Você não acreditaria em quantos estudantes de CS tentarão escrever esse programa imediatamente ... antes de fazer uma aula de computação :)

Supondo que possamos deixar de lado questões morais por um momento:

A empresa A contratou você para uma maneira de se comunicar entre os escritórios satélites A1 e A2 sem que ninguém, além das pessoas autorizadas em A1 e A2, possa entender a comunicação.

A empresa B contratou você para uma maneira inteligente de escutar todas as comunicações entre A1 e A2.

Obviamente você não pode fazer as duas coisas.

Devido à maneira como a matemática funciona (a matemática exata está sujeita a pesquisas em andamento há 100 anos), um dos seguintes requisitos não pode ser atendido:

(1): forneça um algoritmo de criptografia que não pode ser quebrado por um invasor com uma quantia arbitrária de dinheiro disponível.

(2): forneça um algoritmo de quebra de criptografia para um algoritmo de criptografia arbitrário que seja executado em um tempo razoável.

Recentemente, participei de uma aula sobre Business Process Model and Notation ( BPMN ). É fácil ver que os fluxos de trabalho com muitas divisões, junções e loops se tornam rapidamente impraticáveis ​​(embora não necessariamente impossíveis , AFAIK) para entender e controlar (quando você usa muitas divisões OR em vez de divisões XOR).

Para a indústria de software, acho que o mesmo vale para problemas semelhantes de "cobertura de várias condições" na análise de cobertura de código .

Para uma empresa, o caminho a seguir é reduzir o espaço do problema e não jogar mais recursos no problema complexo. No meu exemplo, adicione restrições ao fluxo de trabalho (ou na análise de cobertura de código, simplifique o código), em vez de trabalhar duro para encontrar todos, digamos, N possíveis traços e resultados em que N é um número inimaginavelmente grande.

Além disso, acho que existem muitos problemas na análise de rede / gráfico que são impossíveis de resolver (tentar determinar uma topologia de rede percorrendo iterativamente todos os caminhos etc.).

O exemplo clássico está tentando analisar HTML com expressões regulares . Isso pode funcionar com conjuntos limitados de HTML, mas uma solução geral é impossível, devido ao fato de terem gramáticas diferentes de Chomsky (como o link deixa claro (ish)).

Em geral, algumas pessoas não gostam de pensar filosoficamente (como seu colega de trabalho) e não tenho certeza de que você possa argumentar como se livrar de uma mentalidade. Seu primeiro ponto está certamente errado, mas o segundo pode ser apenas uma maneira de dizer que não preciso me preocupar com isso para codificar formulários da Web para recebimento de mercadorias. Sinto simpatia por isso, mas às vezes conhecer a teoria significa que você não se compromete a encontrar o Santo Graal no horário de trabalho.

Talvez a resposta seja que seu colega de trabalho esteja correto. Talvez você tenha entendido mal Turing, ou como isso se aplica aqui?

Todas as máquinas são finitas, portanto, não existem máquinas de Turing 'reais' nem programas que nunca parem. Um programa trivial que executa um loop infinito simples pode executar 5 minutos ou 50 anos, mas em uma máquina finita ele será interrompido. Um problema não trivial de interrupção, como 'calcular pi exatamente', também será interrompido, porque, eventualmente, o cálculo excederá a capacidade de armazenar mais dígitos.

O resultado de Turing não garante nada de particularmente útil em máquinas finitas; portanto, sua busca é infrutífera. Melhor focar em quanto tempo e quanto dinheiro e deixar o infinito para os matemáticos.

Você pode pensar que um programa como { while true: print "running"; print "halted"; }é um contra-exemplo, mas não é. Este programa tem efeitos colaterais, que podem ou não causar sua interrupção. Ignorando os efeitos colaterais, é possível elaborar uma prova formal de que este programa não será interrompido. Nesta questão, estamos preocupados apenas com programas que escapam à prova formal de não parar, onde a questão da parada é indecidível. Este não é um programa desse tipo.

Pode ajudar a distinguir Turing 'forte' de Turing 'fraco'. As máquinas Strong Turing são infinitas e, se não conseguirem, funcionarão por tempo infinito. Não podemos construí-los.

Máquinas de Turing fracas têm limites finitos de tempo e espaço, e são o único tipo que podemos construir. Estamos interessados ​​em programas que não podem comprovadamente parar dentro desses limites. Turing nos diz que existem programas desse tipo, mas não podemos identificá-los. Se os limites forem baixos o suficiente, podemos identificá-los escrevendo o programa e executando-o em seus limites.

A essência de Turing é que não há atalhos. A única maneira de ter certeza de que um problema é viável computacionalmente é escrever o programa, executá-lo e descobrir. Com tempo e dinheiro suficientes, você pode escrever todos os programas, executá-los para sempre e ao longo do tempo e encontrar os que produzem resultados (os cabeçalhos). Os outros ainda estarão correndo. Você tem tempo e dinheiro suficientes para fazer isso?

Sério, a disputa é sobre limites. Turing e NP complete nos dizem que certas classes de problemas não podem ser resolvidas por computadores dentro de um determinado orçamento ou em um determinado cronograma, não importa quão grande esse orçamento ou quão generoso esse cronograma possa ser. Existem muitos exemplos desse tipo de problema: quebra de chaves criptográficas; otimizar as rotas para fazer entregas em centenas de endereços; caixas de embalagem em caminhões; encontrando bugs em programas grandes!

Portanto, peça um orçamento e um cronograma ao seu colega de trabalho e prometa que você pode produzir um problema que não pode ser resolvido dentro desse orçamento ou cronograma. Essa promessa será muito fácil de cumprir.