インベンターのパラドックス

インベンターのパラドックス（inventor's paradox）とは、与えられた問題の解法を求める際に起こる現象である。具体的な問題を解く方が直感的には簡単そうに見えるが、実際には、求める解の具体例を包含するような一般的な問題を解く方が簡単である場合がある、というパラドックスである。インベンターのパラドックスは、数学、プログラミング、論理学、および批判的思考を伴うその他の分野の現象を説明するために使用されてきた。 ハンガリーの数学者ジョージ・ポリアは、著書『いかにして問題をとくか』の中で、インベンターのパラドックスを次のように定義している。 野心的な計画であればあるほど、成功する可能性が高くなるかもしれない。（中略）それは、ただの自惚れではなく、今あるものを超えたものに対する何らかのビジョンに基づいている場合に限る。 言い換えれば、自分が解決したいことを解決するためには、それ以上のことを解決しなければならないかもしれない。 問題を解決するとき、一般的に自然な傾向として、過剰な変動性をできるだけ排除し、手元にある主題に制限を生じさせようとすることがある。これを行うと、予期せぬ、本質的に厄介なパラメータが発生することがある。目標は、より広範な問題に対して、エレガントで比較的シンプルな解決策を見つけることであり、元々懸念されていた特定の部分に焦点を当てることができるようにすることである。 ここにインベンターのパラドックスがある。なぜなら、一般的な解は当然ながらアルゴリズムがよりシンプルでよりクリーンな設計になっている可能性があるからであり、一般的に、特定の問題と比較して、解決にかかる時間を短縮することができる。 次式のように1から99までの数字の合計を求めることを考える。 1 + 2 + 3 + . . . + 97 + 98 + 99 {\displaystyle 1+2+3+...+97+98+99} この計算は、暗算することも不可能ではないが、ほとんどの人にとっては困難である。しかし、この場合は以下のように順番を並び替えることで、問題を一般化することができる。 ( 1 + 99 ) + ( 2 + 98 ) + ( 3 + 97 ) + . . . + ( 48 + 52 ) + ( 49 + 51 ) + ( 50 ) {\displaystyle (1+99)+(2+98)+(3+97)+...+(48+52)+(49+51)+(50)} この形にすれば、ほとんどの人は電卓等を使わなくても簡単に解くことができる。最も小さい数字1と最も大きい数字99との和が100であり、その次のペア、2と98の和も100であることに気づけば、真ん中の50を除いて、和が100になる49個のペアがあることがわかる。独創的な数学者は、頭の中で問題を「(49×100)+50」と再構成する。49×100は49の数字に2つのゼロを足せば簡単に計算できるので、4900+50となる。これは簡単に足すことができる。なぜなら、50の最上位の桁（十の位の数字5）は、4900の最下位の桁（百の位の数字9）よりも小さいからである。そこで、単に4900の最後の2つの0を50に置き換えて足し合わせるだけで答えが求められ、それは4950になる。このプロセスの文章説明は複雑に見えるが、頭の中で実行される各ステップはシンプルで高速である。 いくつかの応用例があるが、比較的簡単な数列の検査を通して説明するのが最も簡単である。ここで、奇数の和を、小さいものから1つずつ増やして求めることを考える。 1 + 3 = 4 {\displaystyle 1+3=4\,} 1 + 3 + 5 = 9 {\displaystyle 1+3+5=9\,} この数列の続きを見ると、次のようになる。 1 + 3 + 5 + 7 + 9 = 25 {\displaystyle 1+3+5+7+9=25\,} 和を暗算するのは難しいが、数列をある点まで展開させることで、次式のような法則性があることがわかり、問題を簡単にすることができる。 ∑ k = 1 n ( 2 k − 1 ) = n 2 . {\displaystyle \sum _{k=1}^{n}\mathbf {(} 2k-1)=n^{2}.} 同じロジックを適用する上での例として、ある値が25の場合の問題を解くよりも、その値がnの場合として問題を解いてから、それをn=25の場合に適用した方が簡単になるかもしれない。 このパラドックスは、効率的なプログラムを書く際に応用できる。専門化されたプログラムを書くのは直感的であるが、実際には、より一般化された手順を開発する方が簡単になることがある。ブルース・テイト（英語版）によると、成功しているフレームワークのいくつかは、複雑な問題を単純に一般化したものであり、Visual Basic、インターネット、Apache HTTP Serverのプラグインは、そのような実践の主要な例であるとテイトは述べている。 言語の意味論の研究では、多くの論理学者が、自身がこのパラドックスに直面していることに気づく。その応用例として、論理学者は、実際には文が真であると主張できる条件ではなく、文の中の真の条件に関心を持つということが挙げられる。 さらに、このパラドックスは産業界でも応用が可能であることが示されている。 ^ "inventor"は通常は「発明者」「発明家」と訳されるが、このパラドックスにおけるinventorは発明とは関係なく、「問題の解法を創案する人」の意味で使われているため、ここでは訳さずに音訳のままとした。 ^ Pólya, p. 121. ^ a b c Barwise p. 41. ^ a b c d Tate, et al., p. 110 ^ a b Tate, et al., p. 111. ^ Barwise p. 40. ^ Bentley (2000), p. 29. ^ Bentley (1982), p. 79. Barwise, Jon (1989). “Situations in language and logic”. The situation in logic. Center for the Study of Language (CSLI). pp. 327. ISBN 0-937073-33-4  Bentley, Jon Louis (1982). Writing efficient programs. Prentice-Hall. pp. 170. ISBN 0-13-970251-2. https://archive.org/details/writingefficient00bent/page/170  Bentley, Jon Louis (2000). Programming Pearls. Addison-Wesley. pp. 239. ISBN 0-201-10331-1. https://archive.org/details/programmingpearl00bent/page/239  Pólya, Gyorgy (1957). How to solve it: a new aspect of mathematic method. Doubleday. pp. 253. ISBN 0-691-08097-6  Tate, Bruce; Gehtland, Justin (2004). “Allow for Extension”. Better, faster, lighter Java. O'Reilly Media, Inc. pp. 243. ISBN 0-596-00676-4. https://archive.org/details/betterfasterligh0000tate  Welborn, Ralph; Kasten, Vincent A. (2003). “Collaborative DNA: Exploring the Dynamics”. The Jericho principle: how companies use strategic collaboration to find new sources of value. John Wiley and Sons. pp. 276. ISBN 0-471-32772-7. https://archive.org/details/jerichoprinciple0000welb  抽象化 一般化