Qual è un esempio di un problema aziendale computazionalmente impossibile?

Ho un collega che rifiuta di accettare la realtà che le macchine Turing (e le macchine Von Neuman per estensione) non possono risolvere il proprio problema di arresto affermando:

Puoi fare qualsiasi cosa con abbastanza tempo e denaro.

Non ama anche i problemi teorici sostenendo che:

Nel nostro campo, non incontreremo mai queste domande. Siamo sviluppatori di applicazioni, non scienziati teorici.

C'è un buon esempio di un problema aziendale che è impossibile dal punto di vista computazionale che potrei usare per convincerlo?

Non tecnicamente impossibile, ma ...

Pianificazione delle risorse , con l'obiettivo di trovare il programma ideale che massimizzi l'uso delle fasce orarie. Una volta ero su un progetto, nei miei primi giorni di calcolo, che aveva questo requisito. Ci ho lavorato un po 'prima di rendermi conto che era NP-difficile.

Altri esempi di problemi che non sono tecnicamente impossibili, ma tecnicamente difficili, possono essere trovati qui .

La maggior parte dei difficili problemi computazionali nell'informatica aziendale non sono impossibili, ma poco pratici. Il tuo amico ha ragione; puoi risolverli la maggior parte se gli lanci abbastanza denaro. Ma l'argomento è specioso; il punto centrale della gestione di un'azienda è fare soldi, non perderli.

Nella pratica quotidiana, parliamo della completezza di Turing in modo vago, non per dimostrare alcuni principi matematici, ma per illustrare (ad esempio) l'inadeguatezza di HTML e CSS come veicolo completo per la produzione di programmi completi di funzionalità.

Allo stesso modo, il problema dell'arresto è importante per i teorici, ma non ha molta rilevanza per la maggior parte delle aziende.

Altri hanno commentato questo, ma cercherò di scrivere una risposta che dia il mio punto di vista.

Mi piace la risposta di Robert Harvey e i commenti alla sua risposta, e vorrei approfondirli.

Penso che tu debba presentare questi problemi indecidibili (come la risoluzione) in un modo banale: ad esempio, uno strumento IDE che "controlla se questa funzione restituisce sempre un valore".

Durante l'insegnamento, il mio esempio preferito era il refactoring ( equivalenza di funzioni, un altro problema indecidibile ). Ho chiesto:

come controlli se una funzione / programma fa lo stesso dopo il tuo bel refactoring? Certo, abbiamo dei test unitari per questo, ma non coprono tutti i casi. E sono noiosi da scrivere ... Ma siamo programmatori! Dovremmo scrivere un programma che controlli se queste due funzioni stanno producendo sempre lo stesso risultato! Perché non provi a scriverlo?

o, come variazione forse più vicino al tuo caso:

Abbiamo questo codice legacy scritto in un antico dialetto oscuro COBOL, per il quale non esistono specifiche e / o compilatori. Abbiamo solo il programma. Tutta la nostra attività si basa su di essa, quindi dobbiamo essere sicuri al 100% che il nuovo codice Java faccia esattamente lo stesso in ogni situazione. La direzione vuole un programma che lo faccia, controllando tutti i possibili casi e stima che possa essere fatto in 6-8 settimane. Perché non provi a scriverlo?

Il punto non è scrivere un tale programma. O una buona approssimazione dei requisiti. Il punto è rendersi conto che NON può essere fatto in modo diretto, NON sprecare innumerevoli nostri cercando di capire come farlo (solo per rendersi conto che non è possibile), ma riconoscerlo. "Ah! Questo è indecidibile! Non è possibile farlo direttamente. Devo trovare un modo diverso, più intelligente per farlo, con una buona approssimazione".

Devi trovare un modo per presentare il problema in modo riconoscibile e apparentemente semplice. Non crederesti quanti studenti CS cercheranno di scrivere un programma del genere immediatamente ... prima di seguire un corso di calcolabilità :)

Supponendo che possiamo mettere da parte le domande morali per il momento:

L'attività A ha stipulato un contratto con te per un modo di comunicare tra gli uffici satellite A1 e A2 senza che nessuno oltre alle persone autorizzate in A1 e A2 sia in grado di comprendere la comunicazione.

L'attività B si è contratta per un modo di intercettare in modo intelligente tutte le comunicazioni tra A1 e A2.

Ovviamente non puoi fare entrambe le cose.

A causa del modo in cui la matematica funziona (l'esatta matematica è stata oggetto di ricerche in corso per 100 anni), uno dei seguenti requisiti non può essere soddisfatto:

(1): fornire un algoritmo di crittografia che non può essere rotto da un utente malintenzionato con una quantità arbitraria di denaro disponibile.

(2): fornire un algoritmo di interruzione della crittografia per un algoritmo di crittografia arbitrario che viene eseguito in un tempo ragionevole.

Di recente ho seguito un corso su Business Process Model and Notation ( BPMN ). Lì si può facilmente vedere che i flussi di lavoro con troppe divisioni, join e loop diventano rapidamente poco pratici (anche se non necessariamente impossibili , AFAIK) da comprendere e controllare (quando si utilizzano troppe divisioni OR anziché divisioni XOR).

Per l'industria del software, penso che lo stesso valga per problemi simili di "copertura a più condizioni" nell'analisi della copertura del codice .

Per un'azienda, la strada da percorrere è ridurre lo spazio del problema e non gettare più risorse sul problema complesso. Nel mio esempio, aggiungere vincoli al flusso di lavoro, (o nell'analisi della copertura del codice, semplificare il codice), invece di lavorare sodo per trovare tutte, diciamo, N possibili tracce e risultati in cui N è un numero inimmaginabilmente grande.

A parte questo, penso che ci siano molti problemi nell'analisi della rete / grafico che sono impossibili da risolvere (cercando di determinare una topologia di rete percorrendo iterativamente tutti i percorsi, ecc.).

L'esempio classico sta cercando di analizzare HTML con espressioni regolari . Questo può funzionare con insiemi limitati di HTML ma una soluzione generale è impossibile, a causa del fatto che hanno grammatiche diverse di Chomsky (come il link chiarisce (ish)).

Più in generale ad alcune persone non piace pensare filosoficamente (come il tuo collega di lavoro) e non sono sicuro che tu possa discuterne per uscire da una mentalità. Il suo primo punto è certamente sbagliato, ma il secondo potrebbe essere solo un modo per dire che non devo preoccuparmi di questo per codificare i moduli web per la ricezione delle merci. Ho una certa simpatia per questo, ma a volte conoscere la teoria significa che non ti impegni a trovare il Santo Graal sull'orario di lavoro.

Forse la risposta è che il tuo collega ha ragione. Forse hai frainteso Turing o come si applica qui?

Tutte le macchine sono finite, quindi non ci sono macchine di Turing "reali" e nessun programma che non si fermerà mai. Un programma banale che esegue un semplice ciclo infinito potrebbe durare 5 minuti o 50 anni ma su una macchina finita si fermerà. Si interromperà anche un problema non-banale non banale come 'calcola pi esattamente', perché alla fine il calcolo supererà la capacità di memorizzare ulteriori cifre.

Il risultato di Turing non garantisce nulla di particolarmente utile su macchine finite, quindi la tua ricerca alla fine è infruttuosa. Meglio concentrarsi su quanto tempo e quanti soldi e lasciare l'infinito ai matematici.

Potresti pensare che un programma simile { while true: print "running"; print "halted"; }sia un controesempio ma non lo è. Questo programma ha effetti collaterali, che possono o meno causare l'interruzione. Ignorando gli effetti collaterali, è possibile escogitare una prova formale che questo programma non si fermerà. In questa domanda ci occupiamo solo di programmi che sfuggono alla prova formale di non-arresto, in cui la questione dell'arresto è indecidibile. Questo non è un programma del genere.

Può aiutare a distinguere Turing "forte" da "debole". Le macchine di Turing forti sono in realtà infinite e se non riescono a fermarsi, funzioneranno per un tempo infinito. Non possiamo costruirli.

Le macchine di Turing deboli hanno limiti finiti nel tempo e nello spazio e sono l'unico tipo che possiamo costruire. Siamo interessati a programmi che non possono essere dimostrati fermarsi entro tali limiti. Turing ci dice che ci sono tali programmi ma non possiamo identificarli. Se i limiti sono abbastanza bassi possiamo identificarli scrivendo il programma ed eseguendolo ai suoi limiti.

L'essenza di Turing è che non ci sono scorciatoie. L'unico modo per essere certi che un problema sia fattibile dal punto di vista computazionale è scrivere il programma, eseguirlo e scoprirlo. Con abbastanza tempo e denaro puoi scrivere tutti i programmi, eseguirli per sempre e nel tempo e trovare quelli che producono risultati (le cavezze). Gli altri continueranno a correre. Collaboratore ha abbastanza tempo e denaro per farlo?

Scherzi a parte, la disputa riguarda i limiti. Turing e NP complete ci dicono che alcune classi di problemi non possono essere risolte dai computer all'interno di un determinato budget o in un determinato programma, non importa quanto grande sia quel budget o quanto generoso possa essere quel programma. Esempi di questo tipo di problema abbondano: rompere le chiavi crittografiche; ottimizzare i percorsi per effettuare consegne a centinaia di indirizzi; scatole per imballaggio in camion; trovare bug in programmi di grandi dimensioni!

Quindi chiedi al tuo collega un budget e un programma e prometti che puoi produrre un problema che non può essere risolto all'interno di quel budget o programma. Questa promessa sarà molto facile da mantenere.