遺伝的プログラミングを妨げているのは何ですか？
私は遺伝的アルゴリズムを使ってかなりの量の仕事を成功させてきましたが、これまでのところ遺伝的プログラミングを無視しています。私の知る限り、ほとんどのプログラムはプログラマーによって書かれたままですが、遺伝的プログラミングを妨げているものを知りたいのですが。
私が考えたいくつかの可能な説明は次のとおりです。
- 検索スペースが大きすぎて、ノイズの中から有用なプログラムを見つけることができません。
- ほとんどの実際のアプリケーションは、そのようなスペースの適合性評価を可能にするのに十分なデータを提供できません。
- 多くの実際のアプリケーションの有効性を単一のフィットネス指標にまで減らすことは困難です。言い換えれば、適切な適応度関数を作成するには、実際のプログラムを作成するのと同じ量の作業が必要になる可能性があります。
何か案は？
これは私自身の研究で検討してきたことであり、多くの理由があると思います。
GP分野の研究の大部分は、ほとんどのプログラマーによって作成される種類のソフトウェアではなく、数式の作成に焦点を合わせています。この分野には多くのコンピューター科学者がいますが、期待するようなプログラムの作成に焦点を当てている人はほとんどいないため、この分野での進歩は遅れています。
LISPは操作が簡単なニースツリー構造を生成できるため、LISPの使用に重点が置かれていますが、いくつかのトリッキーな問題の解決を伴うため、残念ながら命令型プログラムは無視されてきました。 GPがプログラマーに真剣に受け止められるためには、命令型プログラムを作成する必要があります。
実際のプログラムにはループ構造が含まれていますが、無限ループを防ぐためのあらゆる種類の醜い制約がなければ、ループをGPに実装することは困難です。
遺伝的プログラミングはうまく拡張できません。利用可能な言語が小さい小さな問題には問題ありませんが、最初のポイントで述べたように、検索スペースがすぐに大きくなりすぎます。
人間のプログラマーと比較すると、GPは非常に遅くなる可能性があります。ただし、これは非常に並列化可能であるため、プロセッサコアの数が増えると、大幅にメリットが得られる可能性があります。
もう1つの有効な答えは、コードが自動的に生成されたことを信頼するのは難しいということです。これは本当ですが、GPはそもそも適切な種類のプログラムを作成できないため、実際にはこれが大きな影響を与えるとは思えません。
遺伝的プログラミングの難しい部分は、優れたスコアリング関数を作成することです。
スコアリング関数は、アルゴリズムに目的のプロパティがあるかどうかを正しく判断する必要があります。これは思ったより難しいです-テストスイートを書くよりはるかに難しいです。アルゴリズムは、スコアリング関数のanyの癖に適応し、それを最適化する場合があります。
strcmpを進化させようとしていますか？代わりに、アルゴリズムが合格/不合格のテストケースの長さの数学的パターンを検出する場合があります。スコアリング関数は、テスト対象のアルゴリズムが部分的に機能しているかどうかを判断できる必要があります。遺伝的プログラミングは「ヒルクライミング」に依存しています。小さな有益な突然変異は、スコアの小さな増分改善を引き起こす必要があります。スコアリング関数がtrue/falseしか出力できない場合は、遺伝的にではなく、ランダムに検索しています。
あなたがそれを試してみると、遺伝的プログラミングが水平思考の究極であることがわかります：あなたのプログラムはあなたが考えていなかったあらゆる方法で問題を解決する傾向があります、それらのほとんどは予想外であり（深刻なアプリケーションの場合）おそらく役に立たない。有名な事例の1つは、基本的な電子部品を使用して発振器を進化させる試みでした。回路の単純さと出力が発振するかどうかで判断しました。それは非常に単純なものを生み出し、研究者たちはそれが機能しないと確信していましたが、それは機能しました。それは環境からの電波を拾い上げて増幅することでした。
引用するために編集：
グラハム-ロウ、ダンカン。 「ラジオは電子スープから出てきます。」ニューサイエンティスト、vol.175、no.2358、p.19（2002年8月31日）。オンラインで入手可能 http://www.newscientist.com/news/news.jsp?id=ns99992732
ただし、リンクが壊れているように見えます。
新しいリンクは http://www.newscientist.com/article/dn2732-radio-emerges-from-the-electronic-soup.html
私はこのパーティーに遅れていることを知っていますが、いくつかの点を述べたいと思います。私はジョン・コーザと彼の遺伝的プログラミング4の本で仕事をするという信じられないほどの幸運に恵まれました。
私たちのほとんどが日常的に行っている種類のプログラミング（GUIイベントの接続、ピクセルのプッシュ、データベース化など）は、間違いなくnot GPが構築しようとしているプログラムの種類です。
John Kozaが約100台のマシンのクラスターで行うこと（私が正しく覚えている場合）は、興味深い問題の解決策を探すことです（NP困難だと考えてください）。悲しいことですが、私たちプログラマーが日々取り組んでいる問題のほとんどは、それほど面白くなく難しい問題ではなく、ほとんどの場合、苛立たしくて時間がかかるだけです。
遺伝子操作された電子発振器についてベン・ジャクソンが言ったことは、このスレッドでコザ博士とチームが実際に行っていることに最も近いことです。 GPシリーズの本には回路の例がたくさんありました。
トムキャッスルが命令型プログラムについてここで言ったことは、正確には真実ではありません。ジョンと会社からのこれの独創的な例は、アンテナ設計の実行です。これは、アンテナを設計するLOGO描画言語のようなコマンドを使用した3D描画プログラムです。スタック上で行列をプッシュおよびポップするためのmoveto、linetoタイプのコマンドがあります。先週見たGPパッケージjgapは、直接サポートされています。つまり、void returnステートメントを含むことができ、最後にreturnステートメントを持つコンテナータイプの非終端記号です。あまり詳しくは見ていませんが、ローカル変数のようなものもあると思います。
初期のGPが中心に実行されている元のLISP設計は、時々一種の苦痛であり、それは確かに真実です。これは通過儀礼のようなもので、GPランの出力をより使いやすいコードに変換することに悩まされていると思います。
TL; DR：GPは実際には自動プログラミングシステムではありません。自動化された発明システムです。
私は1と3と言います。
特に、ポイント3に関しては、適切なターゲット関数を考え出すよりも、実際のプログラムを書く方が簡単である場合がほとんどですそしてこれを確認してください正しいまたは許容できる解決策につながります（遺伝的プログラミングから派生したアルゴリズムが期待どおりに機能することをどのように知っていますか？）
ポイント1に関しては、探索空間には無限の次元があると言えます。
GPは、適応度関数を作成する人の知識を超えた新しい問題を迅速に解決することはできません。そのため、現在、解決方法がすでにわかっている問題の解決にのみ使用できますが、検索スペースが原因で完全に解決するには理想的ではありません。巡回セールスマンなど。これはGAでより迅速に解決できます。
理由は実際にはかなり単純です。新しい問題を解決するには、GPに提供するツールは、GP検索空間が実際の遺伝学の真の類似物になるように、十分に単純であるか、十分に完全である必要があります。
遺伝的プログラミングは、実際の遺伝学と同様に、すべてのプラットフォーム成長システムと同じ成長パターンの影響を受けます。つまり、GPは、含まれているコアユーティリティがプラットフォームにヒットし、横ばい状態になり、新しいパラダイムに遭遇して新しいプラットフォームを構築するまでに長い時間がかかります。
このプロエボリューションビデオは、これらのプラットフォームの成長パターンを示しています。 http://www.youtube.com/watch?v=mcAq9bmCeR 新しいハンドを開発するには長い時間がかかりますが、開発すると、追加のハンドが新しいものになり、すぐにより多くの手の最適な例。 （このビデオはGPではなくGAを使用している可能性が高いですが、遺伝学は遺伝学です）
これはすべて、特異性理論、ところで入るのとほぼ同じ論理です。
しかし、これがGPにとって意味することは、それがかなり-研究にのみ有効であり、プログラム内での実用化には有効ではないということです。要件がGAで解決できるよりもわずかに詳細である、いくつかの単純な例外を除いて。一部のスケジューラプログラムなど。プログラミング検索スペースが非常に小さく、ツールが必要な場合それを解決することはよく理解されており、明確に定義された適応度関数が存在する可能性があります。
三つの事：
- アンドレは言う のように、十分な適応度関数を書くのは非常に難しいです。これは、テスト駆動開発の究極のバージョンです。まだ書かれていないプログラムを100％カバーする単体テストを作成する必要があります。それでも、100％のカバレッジだけでは十分ではありません。複雑なシステムのすべての側面の正確な動作を正式に指定し、特定のプログラムがその仕様を満たしていることを確認するという問題を解決したら、チャンスがあるかもしれません。
- 遺伝的プログラミングは非決定論的であり、正確な解よりも近似解を生成するのに適しています。
- 遺伝的プログラミングは、合理的な複雑さの問題に適用されると、驚くほど計算コストが高くなります。 1999年に、 Genetic Programming Incは1,000ノードのクラスターを使用していました 現場での作業に。
それは、理論的に不可能であることが証明されているからです（少なくとも正しいプログラムでは）。
検索スペースのサイズや速度の問題、その他の「速度」を破棄する無限の計算能力があると仮定しましょう。今、あなたはたった2つの問題に直面しています：-生成されたプログラムは停止しますか？ -生成されたプログラムが希望どおりに動作することを確認するにはどうすればよいですか？
最初の問題は計算可能性理論の中心的な問題であり、 停止問題 と呼ばれます。チューリングは1936年に、この問題がすべてのプログラムと入力のペアで決定不可能であることを証明しました。これは、場合によっては可能ですが、すべてではないことを意味します。プログラムが停止するかどうかを判断できる自動化されたプロセスはありません。したがって、これについては、多くのことを行うことはできません;）
プログラムの正当性に関連する2番目の問題。遺伝的プログラミングでは、検証は通常、正当性の証明をまったく構成しない値の例を通じて行われます。これは単体テストに匹敵し、多くの例で問題ありませんが、一般的な証拠はありません。たとえば、素数チェッカーを作成し、3 5 7と11でのみテストすると、奇数ごとにtrueを返すプログラムがテストに合格します。
さらに一歩進むと、自動証明を使用することになります。アルゴリズムの正当性の自動証明は、実際、数学的な自動定理証明と深く関係しています。公理化されたシステムを使用してプログラムを記述し、ステートメントの正しさを自動的に証明しようとします。ここでも、強い理論的障壁に直面しています。それは ゲーデルの不完全性定理 です。これらの定理は、とりわけ、自然数に対して算術演算を実行できる非常に単純な公理化されたシステムでさえ、これらの自然数に関するすべての定理を証明できるアルゴリズム（効果的な手順と呼ばれる）がないことを述べています。具体的には、単純なプログラムでもその正しさを証明できないということです。
証明された正確性がなくても、サンプルテストケースを使用して遺伝的プログラムを検証すると、機械学習での過剰適合として知られる現象である過度の専門化が非常に起こりやすくなります。つまり、学習したプログラムは、提供されたテストケースでは問題なく機能しますが、他のいくつかの入力では完全に弾道的になる可能性があります。
その理由の大部分はリスク管理だと思います。私に耐えてください：プログラマーがプログラムを書くために座っているとき、彼らはそれがどれくらいの時間がかかるか、そして彼らが何ができるかについて少なくともある程度の考えを持っています。
代わりに、プログラマーが（遺伝的プログラミングを使用して）プログラムを生成するプログラムを書くために座っているとき、不確実性が屋根を突き破ります。プロセスにかかる時間は不明であり、最終プログラムがどれほど優れているかは不明です。
他の場所にも不確実性があります。後でプログラムを調整したり、バグを修正したりするのはどれほど簡単でしょうか。生成されたコードは、デバッグがほぼ不可能な場合があります。
たぶん、ほとんどのプログラマーはプログラマーであり、コンピューター科学者ではないのでしょうか。
遺伝的プログラミングには真剣な賢さが必要です。問題を適切に分解できる必要があり、最初に適切な問題が必要です。そして、遺伝的アルゴリズムがオプションであることを知るのに十分な知識が必要です。そして、問題はまだよく知られた解決策を持っている必要はありません。
すべてが凝ったアルゴリズムを必要とするわけではありません。世界で書かれているすべてのコードの中で、「標準的な」ウェブアプリ、OS、デバイスプログラミングは本当に遺伝的アルゴリズムを必要としますか？
そして、結局のところ、ほとんどのプログラミング作業は、複雑なアプローチが必要ない単純な問題の解決に費やされています。
大学でのGP研究に数年携わった後、その後この分野をフォローした後の私の個人的な見解：GPは拡張できません。
単純な適応度関数GPで表される単純な問題は、問題なく解決できます。しかし、前述のように、strcmpや計算機、さらには単純なテキストエディターを進化させるタスクを説明する適応度関数を作成することは、従来のアプローチではほとんど不可能です。
GPフィットネス関数が完全にTDDであるという概念は好きですが、:-)いつか、シミュレートされた進化を指示するためのより良い方法を思いつくかもしれませんが、それはまだ実現していません。
私は現在いくつかの「私的研究」を行っている陰関数的適応度関数の分野でGPにいくつかの希望を持っています。どこまで到達するか見ていきます！
乾杯、ジェイ
原始的なスープは疑わしく、食欲をそそりません。私のプロダクションコードには、インテリジェントデザインが好きです。
GPでは上記の問題に取り組むプロジェクトがいくつかあります。例は opencog MOSES
GPとGA、または一般的に進化的アルゴリズムは趣味のようなものです。例外を除いて、実際のアプリケーションには使用されません。その理由は、これらのアルゴリズムがランダム性に基づいているためです。良い答えが得られるかどうかは定かではありません。
さらに、この領域は、他の数学的に強力な手法と比較して理解と実装が容易であるため、標準以下の研究作業で溢れています。そのため、学生は工学や科学のアプリケーションで最適化する目的を見つけるだけで、公開される新しい仕事があります。
会議のスポンサーを他のAI/ML /最適化会議のスポンサーと比較するだけです。業界における彼らの「現在の」重要性については明らかです。
しかし、それは研究分野であり、それを機能させるのは私たち次第です。現在は趣味です！
今日、プログラミングは機械可読な方法で細かい仕様を定義しています。プログラムに、実行したいことと、結果がどのように表示されるかを正確に伝えます。もうそれほど多くはありません。つまり、たとえば次の方法で結果を生成する場合です。遺伝的プログラミングでは、この機械可読な細かい仕様を適応度関数の形で実行する必要があります。これは、少なくとも同じですが、おそらくより多くの作業につながります。したがって、定義は簡単だが仕様に到達するのが難しい問題のために作られた遺伝的プログラミングにとっては、まさに間違った分野です。
編集：ほとんどのプロジェクトでは、この細かい仕様はとにかくテストの形で行われていると言えます。遺伝的プログラミングのアプローチでは、テストはあなたが必要としていることを不正確に特定する方法だと思います。それらは例に基づいており、形式仕様言語に基づくプログラミングとは異なります。遺伝的プログラミングは、おそらくテストケースに適した結果を生成し、新しい入力を使用した実際の状況では正しく動作しません。したがって、プログラミング言語の仕様と同じくらい正確なテストの仕様レベルを取得するには、不測の事態に備えて膨大な量のテストケースが必要になります。したがって、最終的には、プログラミングよりもはるかに多くの作業を行うことになります。