Quel est un exemple d'un problème commercial impossible à calculer?

J'ai un collègue qui refuse d'accepter la réalité que les machines Turing (et les machines Von Neuman par extension) ne peuvent pas résoudre leur propre problème d'arrêt en déclarant:

Vous pouvez tout faire avec suffisamment de temps et d'argent.

Il n'aime pas non plus les problèmes théoriques faisant valoir que:

Dans notre domaine, nous ne rencontrerons jamais ces questions. Nous sommes des développeurs d'applications, pas des scientifiques théoriques.

Existe-t-il un bon exemple de problème commercial impossible sur le plan informatique que je pourrais utiliser pour l'aider à le convaincre?

Pas techniquement impossible, mais ...

Planification des ressources , dans le but de trouver le calendrier idéal qui maximise l'utilisation des plages horaires. J'étais sur un projet une fois, dans mes premiers jours informatiques, qui avait cette exigence. J'y ai travaillé un certain temps avant de réaliser que c'était NP-difficile.

D'autres exemples de problèmes qui ne sont pas techniquement impossibles, mais qui sont techniquement difficiles, peuvent être trouvés ici .

La plupart des problèmes de calcul difficiles dans l'informatique d'entreprise ne sont pas impossibles, mais peu pratiques. Votre ami a raison; vous pouvez résoudre la plupart d'entre eux si vous leur jetez suffisamment d'argent. Mais l'argument est spécieux; tout l'intérêt de gérer une entreprise est de gagner de l'argent, pas de le perdre.

Dans la pratique quotidienne, nous parlons de l'intégralité de Turing d'une manière vague, non pas pour démontrer un principe mathématique, mais pour illustrer (par exemple) l'insuffisance de HTML et CSS en tant que véhicule complet pour produire des programmes complets.

De même, le problème de l'arrêt est important pour les théoriciens, mais il n'a pas beaucoup de pertinence pour la plupart des entreprises.

D'autres ont commenté cela, mais je vais essayer d'écrire une réponse donnant mon point de vue.

J'aime bien la réponse de Robert Harvey et les commentaires de sa réponse, et j'aimerais les développer.

Je pense que vous devez présenter ces problèmes indécidables (comme la terminaison) de manière banale: par exemple, un outil IDE qui "vérifie si cette fonction renvoie toujours une valeur".

Lors de l'enseignement, mon exemple préféré était le refactoring ( équivalence de fonction, autre problème indécidable ). J'ai demandé:

comment vérifiez-vous si une fonction / programme fait de même après votre refactoring sympa? Bien sûr, nous avons des tests unitaires pour cela, mais ils ne couvrent pas tous les cas. Et ils sont ennuyeux à écrire ... Mais nous sommes programmeurs! Nous devons écrire un programme qui vérifie si ces deux fonctions produisent toujours le même résultat! Pourquoi n'essayez-vous pas de l'écrire?

ou, comme une variante peut-être plus proche de votre cas:

Nous avons ce code hérité écrit dans un ancien dialecte COBOL obscur, pour lequel aucune spécification et / ou compilateur n'existe. Nous n'avons que le programme. Toute notre entreprise en dépend, nous devons donc être sûrs à 100% que le nouveau code Java fait exactement la même chose dans chaque situation. La direction veut un programme qui le fasse, vérifiant tous les cas possibles, et estime que cela peut être fait en 6 à 8 semaines. Pourquoi n'essayez-vous pas de l'écrire?

Il ne s'agit pas d'écrire un tel programme. Ou une assez bonne approximation des exigences. Le but est de réaliser que cela ne peut PAS être fait de manière directe, ne gaspillez PAS d'innombrables nôtres en essayant de comprendre comment le faire (seulement pour réaliser que ce n'est pas possible), mais reconnaissez-le. "Ah! C'est indécidable! Ce n'est pas possible de le faire directement. J'ai besoin de trouver une manière différente, plus intelligente de le faire, avec une approximation suffisamment bonne".

Vous devez trouver un moyen de présenter le problème d'une manière reconnaissable et apparemment simple. Vous ne croiriez pas combien d'étudiants CS essaieront d'écrire un tel programme tout de suite ... avant de suivre un cours de calculabilité :)

En supposant que nous pouvons mettre de côté pour le moment les questions morales:

L'entreprise A a passé un contrat avec vous pour un moyen de communiquer entre les bureaux satellites A1 et A2 sans que personne d'autre que les personnes autorisées en A1 et A2 ne puisse comprendre la communication.

L'entreprise B vous a confié un moyen d'écouter intelligemment toutes les communications entre A1 et A2.

De toute évidence, vous ne pouvez pas faire les deux.

En raison de la façon dont les mathématiques fonctionnent (les mathématiques exactes font l'objet de recherches continues depuis 100 ans), l'une des exigences suivantes ne peut pas être satisfaite:

(1): Fournissez un algorithme de chiffrement qui ne peut pas être brisé par un attaquant avec une somme d'argent arbitraire disponible.

(2): Fournissez un algorithme de rupture de chiffrement pour un algorithme de chiffrement arbitraire qui s'exécute dans un délai raisonnable.

J'ai récemment suivi un cours sur le modèle de processus métier et la notation ( BPMN ). Là, il est facile de voir que les flux de travail avec beaucoup trop de divisions, de jointures et de boucles deviennent rapidement impraticables (mais pas nécessairement impossibles , AFAIK) à comprendre et à contrôler (lorsque vous utilisez trop de divisions OR au lieu de divisions XOR).

Pour l'industrie du logiciel, je pense qu'il en va de même pour des problèmes similaires de "couverture de conditions multiples" dans l' analyse de couverture de code .

Pour une entreprise, la voie à suivre consiste à réduire l'espace du problème et à ne pas consacrer davantage de ressources au problème complexe. Dans mon exemple, ajoutez des contraintes au flux de travail (ou, dans l'analyse de la couverture de code, simplifiez le code), au lieu de travailler dur pour trouver tous, disons, N traces et résultats possibles où N est un nombre incroyablement élevé.

En dehors de cela, je pense qu'il y a de nombreux problèmes dans l' analyse de réseau / graphique qui sont impossibles à résoudre (essayer de déterminer une topologie de réseau en parcourant de manière itérative tous les chemins, etc.).

L'exemple classique essaie d' analyser le HTML avec des expressions régulières . Cela peut fonctionner avec des ensembles limités de HTML mais une solution générale est impossible, car ils ont des grammaires Chomsky différentes (comme le lien le montre clairement (ish)).

Plus généralement, certaines personnes n'aiment pas penser philosophiquement (comme votre collègue) et je ne suis pas sûr que vous puissiez discuter de votre façon de sortir d'un état d'esprit. Son premier point est certainement faux, mais son second pourrait simplement être une façon de dire que je n'ai pas besoin de m'inquiéter à ce sujet pour coder les formulaires Web pour la réception des marchandises. J'ai de la sympathie pour cela, mais parfois, connaître la théorie signifie que vous ne vous engagez pas à trouver le Saint Graal pendant le temps de travail.

La réponse est peut-être que votre collègue a raison. Peut-être avez-vous mal compris Turing ou comment cela s'applique-t-il ici?

Toutes les machines sont finies, il n'y a donc pas de «vraies» machines de Turing et aucun programme qui ne s'arrêtera jamais. Un programme trivial qui exécute une boucle infinie simple pourrait durer 5 minutes ou 50 ans, mais sur une machine finie, il s'arrêtera. Un problème non trivial sans interruption tel que «calculer exactement pi» s'arrêtera également, car finalement le calcul dépassera la capacité de stocker d'autres chiffres.

Le résultat de Turing ne garantit rien de particulièrement utile sur les machines finies, donc votre quête est finalement infructueuse. Mieux vaut se concentrer sur combien de temps et combien d'argent et laisser l'infini aux mathématiciens.

Vous pouvez penser qu'un programme comme { while true: print "running"; print "halted"; }est un contre-exemple, mais ce n'est pas le cas. Ce programme a des effets secondaires qui peuvent ou non provoquer son arrêt. En ignorant les effets secondaires, il est possible de concevoir une preuve formelle que ce programme ne s'arrêtera pas. Dans cette question, nous ne nous intéressons qu'aux programmes qui échappent à la preuve formelle de non-arrêt, où la question de l'arrêt est indécidable. Ce n'est pas un tel programme.

Il peut être utile de distinguer Turing «fort» de Turing «faible». Les machines de Turing fortes sont en fait infinies et si elles ne s'arrêtent pas, elles fonctionneront pendant une durée infinie. Nous ne pouvons pas les construire.

Les machines de Turing faibles ont des limites finies de temps et d'espace, et ce sont les seules que nous pouvons construire. Nous sommes intéressés par des programmes dont il est impossible de prouver qu'ils s'arrêtent dans ces limites. Turing nous dit qu'il existe de tels programmes mais nous ne pouvons pas les identifier. Si les limites sont suffisamment basses, nous pouvons les identifier en écrivant le programme et en l'exécutant à ses limites.

L'essence de Turing est qu'il n'y a pas de raccourcis. La seule façon d'être certain qu'un problème est réalisable par calcul est d'écrire le programme, de l'exécuter et de le découvrir. Avec suffisamment de temps et d'argent, vous pouvez écrire tous les programmes, les exécuter indéfiniment et dans le temps, et trouver ceux qui produisent des résultats (les licols). Les autres seront toujours en cours d'exécution. Votre collègue a-t-il suffisamment de temps et d'argent pour le faire?

Sérieusement, le différend porte sur les limites. Turing et NP complete nous indiquent que certaines classes de problèmes ne peuvent pas être résolues par des ordinateurs dans un budget donné ou selon un calendrier donné, quelle que soit la taille de ce budget ou la générosité de ce calendrier. Les exemples de ce type de problème abondent: rupture des clés cryptographiques; optimiser les itinéraires pour effectuer des livraisons à des centaines d'adresses; boîtes d'emballage dans des camions; trouver des bugs dans les grands programmes!

Demandez donc à votre collègue un budget et un calendrier et promettez que vous pouvez produire un problème qui ne peut pas être résolu dans ce budget ou ce calendrier. Cette promesse sera très facile à tenir.