計算上不可能なビジネス問題の例は何ですか？
私には、チューリングマシン（およびフォンノイマンマシン）が自分の停止問題を解決できないという現実を受け入れることを拒否する同僚がいます。
十分な時間とお金があれば何でもできます。
彼はまた、次のことを主張する理論的な問題を嫌います。
私たちの分野では、これらの質問に遭遇することは決してありません。私たちは理論開発者ではなく、アプリケーション開発者です。
このことを彼に納得させるために私が使用できる、計算上不可能なビジネス問題の良い例はありますか？
技術的に不可能ではありませんが...
リソースのスケジュール 、タイムスロットの使用を最大化する理想的なスケジュールを見つけることを目的とします。私は以前のコンピューティング時代に、この要件があったプロジェクトに1回参加していました。それがNP困難であることに気付く前に、私はしばらくそれに取り組んだ。
技術的に不可能ではないが技術的に難しい問題の他の例は、 ここ で見つけることができます。
ビジネスコンピューティングにおける最も難しい計算上の問題は不可能ではなく、実際的ではありません。あなたの友達は正しいです。あなたがそれらに十分なお金を投げればあなたはそれらのほとんどを解決することができます。しかし、その議論は疑わしいものです。ビジネスを運営することのすべてのポイントは、お金を稼ぐことであり、失うことではありません。
日常の練習では、数学の原理を示すためではなく、機能の完全なプログラムを作成するための完全な手段としてのHTMLおよびCSSの不適切さを示すために、漠然とした方法でチューリングの完全性について話します。
同様に、停止問題は理論家にとって重要ですが、ほとんどのビジネスにはあまり関係がありません。
他の人がこれについてコメントしましたが、私は私の見解を与える答えを書き出そうとします。
私はロバート・ハーヴェイの回答と彼の回答へのコメントが好きです。
これらの決定不可能な問題（終了など）を平凡な方法で提示する必要があると思います。たとえば、IDE「この関数は常に値を返すかどうかをチェックする」ツールです。
教えるとき、私のお気に入りの例はリファクタリング（ 関数の等価性、もう1つの決定不可能な問題 ）でした。私は尋ねた：
ナイスリファクタリング後に関数/プログラムが同じように機能するかどうかをどのように確認しますか？もちろん、そのための単体テストはありますが、すべてのケースを網羅しているわけではありません。そして、彼らは書くのが退屈です...しかし、私たちはプログラマーです！これらの2つの関数が常に同じ結果を生成するかどうかをチェックするプログラムを作成する必要があります。書いてみませんか？
または、バリエーションとしてあなたのケースに近いかもしれません：
このレガシーコードは、仕様やコンパイラーが存在しない古代のあいまいなCOBOL方言で記述されています。私たちはプログラムだけを持っています。私たちのビジネス全体がそれに依存しているので、新しいJavaコードがすべての状況でまったく同じように機能することを100％確認する必要があります。経営陣は、すべての可能なケースをチェックし、それを行うプログラムを望んでいます。 6〜8週間でできると推定していますが、書いてみませんか？
ポイントは、そのようなプログラムを書くことではありません。または、要件の十分に良い概算です。重要なのは、それが直接的な方法で実行できないことを認識し、それを行う方法を理解しようとする無数の私たちを無駄にせず（それが不可能であることを理解するためだけに）、それを認めることです。 「ああ！これは決定不可能です！直接行うことは不可能です。十分に良い近似で、別のより賢い方法を理解する必要があります。」.
あなたは問題を認識できる、そして明らかに単純な方法で提示する方法を理解しなければなりません。信じられないでしょう 計算プログラムのクラスを受講する前に、CSプログラムの学生がこのようなプログラムをすぐに書き込もうとする人の数 ...
今のところ、道徳的な質問を別にしておくと仮定します。
ビジネスAは、A1とA2の承認された人以外の人が通信を理解できないようにして、サテライトオフィスA1とA2の間で通信する方法について契約しました。
企業Bは、A1とA2の間のすべての通信をインテリジェントに盗聴する方法についてあなたに契約しています。
もちろん、両方を行うことはできません。
数学の計算方法により（正確な数学は100年間継続的に研究されてきました）、次の要件のいずれかを満たすことができません。
（1）：任意の金額を利用できる攻撃者が解読できない暗号化アルゴリズムを提供します。
（2）：妥当な時間内に実行される任意の暗号化アルゴリズムに暗号解読アルゴリズムを提供します。
私は最近、ビジネスプロセスモデルと表記法（ [〜＃〜] bpmn [〜＃〜] ）のクラスを受講しました。分割、結合、ループが多すぎるワークフローは、すぐに非現実的になることが容易にわかります（ただし、必ずしも不可能、AFAIK）理解して制御することはできませんが、 （XORスプリットの代わりに使用するORスプリットが多すぎる場合）。
ソフトウェア業界の場合、 コードカバレッジ分析 の「複数条件カバレッジ」の同様の問題についても同じことが言えると思います。
ビジネスの場合、進むべき道は、問題の領域を縮小することであり、複雑な問題にさらに多くのリソースを投入しないことです。私の例では、ワークフローに制約を追加します（または、コードカバレッジ分析では、コードを簡略化します）。たとえば、Nが考えられないほど大きな数であるすべての可能性のあるトレースと結果を見つけるのではなく、.
それとは別に、 network / graph 分析には解決できない多くの問題があると思います（すべてのパスを繰り返し歩くなどしてネットワークトポロジーを決定しようとします）。
古典的な例は 正規表現でHTMLを解析する を試みています。これは限られたHTMLのセットで機能しますが、チョムスキーの文法が異なるため、一般的な解決策は不可能です（リンクが明らかにするように）。
より一般的には、一部の人々は（同僚のように）哲学的に考えることを好まないため、マインドセットから自分のやり方を論じることができるかどうかはわかりません。彼の最初の点は確かに間違っていますが、彼の2番目の点は、商品受け取り用のWebフォームをコーディングするためにこれを心配する必要がないと言っているだけかもしれません。私はこれに同情していますが、時には理論を知っているということは、勤務時間中に聖杯を見つけることに専心しないことを意味します。