"New Neural "は、MetaTrader 5プラットフォーム用のオープンソース・ニューラルネットワークエンジンプロジェクトです。 - ページ 62 1...555657585960616263646566676869...100 新しいコメント Mykola Demko 2011.11.24 21:42 #611 ジュどちらが速いかは明らかです。しかし、トレーニング全体で何回ファイルに書き込む必要があるのでしょうか？- 一度だけ？そのため、速度は重要ではありませんが、視覚的なコントロールは簡素化されています。xml-fileなら視覚的にコントロールしやすいとは言えませんね。それでも何らかのテンプレートをxml-fileとして使うことはできますが、1つのレイヤーに1500個のニューロンがあるグリッドを可視化するのは面倒なので、xml-fileを作る手間がかかり、とにかく良い可視化はできないでしょう。拒否はしませんが、保存すると、xmlでも複製が可能です。MetaDriver。初期化とは どういうことでしょうか？ ウエイトをロードするのであれば、それは一つの方法です。グリッドの設定＋ウェイトの読み込みが別物なら。--そうですね。歌います。中間ネットワークの構成（構造、型）をmql5コードにマッピングする方法は2つあります。1つ目：初期化時にライブラリクラスからネットワークを動的に設定する。このようなネットワークには、動的な配列や ポインタによるリンクが多く、これまでは暗黙のうちにこの方法が主流でした。しかし、もう一つの方法があります。それは、事前設定とxmlへのマッピングを行った後、リジッドメッシュ（静的配列と目的のアドレス（インデックス）への直接アクセスを持つ）を生成する方法です。このようなエンジンは、生成されるグリッドがより高速になるため、ユーザーにとってより魅力的なものになる可能性があります。実際、xml2mqlのコンパイラを作る必要があります。私は、実は、2つ目の方法に賛成です。 行き詰まったときに、メタ引用が助けになることを願っています。第一の方法2番目の選択肢は、（正確には覚えていませんが、最初のページで）破棄されました。なぜなら、将来的に「ユーザー」のカテゴリには、F7が何であるかを知らない人が含まれることになるからです。また、このエンジンは簡単に拡張できるようになっており、F7の目的を知っている人なら、別の種類のグリッドを追加したり、自分で発明したりすることができます。ZY テンプレートコーディングへのこだわりは理解できますが、2番目の方法については、学習アルゴリズムの実装とニューロンタイプの拡張の両方に大きな問題があり、さらにGPUに最適化する必要があることに同意します。最初のバリエーション、誰もができる最もシンプルなものには深刻な問題があり、ユニバーサル エンジンのプロジェクトを説明するだけでも頭がパンクしそうです。 yu-sha 2011.11.24 21:55 #612 明日は、ネットワークプロトタイプの保存、トレーニングタスクの設定、見つかったソリューションの保存などの作業を、仕事場のパソコンからここにコピーします。すべてxmlでxmlファイルのパースによるリソース集約は誇張されすぎていると思います。これは1回限りの処置であることをお忘れなく。さらに、MQL5用のネイティブなxmlファイルパーサを書くことは、ニューラルネットワークプロジェクトの 複雑さに比べれば、些細なことです。 Vladimir Gomonov 2011.11.24 22:08 #613 ウラン です。第一の方法2つ目の選択肢は、今後、F7が何であるかを知らない人が「ユーザー」に入隊することになるので、（正確には覚えていませんが、最初のページで）破棄されました。それに、このエンジンは簡単に拡張できるはずで、F7の目的を知っている人なら、自分用にメッシュを追加したり、自分で発明したりすることができます。メッシュタイプの力量不足で1つだけ質問させてください。メッシュの種類はルックアップテーブルで一意に定義できるのか、つまり、与えられたルックアップテーブルに従うだけの普遍的な抽象メッシュを作ることはできるのか？つまり、真にユニバーサルな ネットワークということでしょうか。もし答えが「はい」なら、グリッドタイプは中間ビューが作成される前に グリッド構成エディターで定義され、ユニバーサルライブラリの修正は必要ありません。つまり、グリッド構造がどうであれ、（不具合がなければ）決して必要ない。 できることといえば、最適化、非線形コンバータやトレーニング方法などのライブラリの拡張くらいだろう。 もし「いいえ」なら、この方法に当てはまらない例外について、自由にリンクを貼ってください。--ネットワーク記述のxml表現が徹底的に考え抜かれ、mql実装から完全に抽象化されている（これは正しい）なら、代替案は矛盾していないように見えます。どちらも実装可能なだけでなく、必要に応じて相互乗り入れも可能です。 Mykola Demko 2011.11.24 22:15 #614 MetaDriver。...答えは二者択一ではありません。 一方では否定的な答えもある。リレーションシップテーブル自体には、ニューロンのタイピングは指定されていないのだ。一方、答えは肯定的で、数値で型を指定することも可能です（共通の祖先から継承した特定の型のオブジェクトをスイッチで作成します）。つまり、全体としては、パラメトリック配列とリレーションシップテーブルで問題ないのです。しかし一方で、コンフィギュレーションエディターにもパラメータ（層数、各層のニューロン数、層のニューロンの種類）があり、それはリンクを作成する前のものです。 TheXpert 2011.11.24 22:36 #615 MetaDriver。つまり、真にユニバーサルな ネットワークということでしょうか。 フィードフォワードからはい。その他は、トポロジーを見る必要があります。 Vladimir Gomonov 2011.11.24 22:50 #616 TheXpert です。 フィードフォワードから、ですね。その他は、トポロジーを見る必要があります。トポロジーはリンケージテーブルによって設定される......。? TheXpert 2011.11.24 23:00 #617 MetaDriver。トポロジーはリンケージ・テーブルで設定される・・・。 そして、連動させる部品の機能。 Vladimir Gomonov 2011.11.24 23:24 #618 TheXpert です。 そして、連動させる部品の機能。よし、ここでもう少し詳しく説明しよう。この機能は有限の（小さな）表で与えられるか？ 異なるタイプのニューロン（活性化関数は別として）の違いは何か？ TheXpert 2011.11.24 23:37 #619 MetaDriver。よし、ここでもう少し詳しく説明しよう。この機能は有限の（小さな）テーブルで与えられるのか？ 異なるタイプのニューロン（活性化関数は別として）の違いは何か？厳密には、そうではありません。 まず簡単なケースを紹介します。例えば、リニア、シグモイド、タンジェントのニューロンがあるとします。新しいタイプのアクティベーションを追加したい場合は、アクティベーションタイプの列挙を拡張する必要があります。基本的に、だからどうした。その前に、例えばKohonenネットワークでは、なぜ出力層にsome=someの活性化関数の符号が必要なのでしょうか？これは余分な冗長な情報です。第二に、このリストは理論上、無制限である。第三に、ネットワークごとに運用や配置に特殊性がある場合があります。例えば、コホネンネットワーク（SOM）では、近傍関数の設定と、結果を出力として出力するか、リーダのみ（リーダ以外をゼロにする）かのフラグを設定することが可能です例えば、論理モデルでは、設定可能なパラメータは活性化関数にある。これは一般的なモデルにもあるのでしょうか？MLP層では、単一のニューロン存在フラグである可能性があります。____________________________ところで、バイナリ表現よりもxmlの方が妥当性をチェックしやすい。また、保存・復元は基本的にタイムクリティカルではありません。 Vladimir Gomonov 2011.11.25 00:20 #620 TheXpert: 1. 厳密には、ありません。まず簡単なケースを紹介します。例えば、リニア、シグモイド、タンジェントのニューロンがあるとします。新しいタイプのアクティベーションを追加したい場合は、アクティベーションタイプの列挙を拡張する必要があります。基本的には、だからどうした、ということです。その前に、例えばKohonenネットワークでは、なぜ出力層にsome=someの活性化関数の符号が必要なのでしょうか？これは不必要で余分な情報です。第二に、このリストは理論上、無制限である。第三に、ネットワークはそれぞれ運用や構造に特殊性がある場合があります。例えば、コホネンネットワーク（SOM）では、近傍関数の設定と、結果を出力として出力するか、リーダのみ（リーダ以外をゼロにする）かのフラグを持つことができる。例えば、論理モデルでは、設定可能なパラメータは活性化関数にある。これは一般的なモデルにもあるのでしょうか？MLP層では、1つのニューロンを持つことがフラグとなる可能性があります。____________________________2. ちなみに、xmlはバイナリ表現に比べ、妥当性のチェックが非常に容易です。また、Saving Recoveryは基本的にタイムクリティカルではありません。1. なぜダメな のか私のアイデアは次のようなものです。普遍的な「要素ベース」を作り、そこからあらゆるタイプのニューラルネットワークを「ハンダ付け」できるようにすることです（拡張可能である可能性もあります）。このベースの要素は、厳密で曖昧さのない定義、つまり数式で定義されます。必要に応じて、擬似コードの応用で。しかし、実装から切り離すために、mql-codeの形ではなく、時間と共に改善することができます。 抽象的な要素ベースを作成した後（可能であれば）、要素間のすべての接続を記述できるxml-ファイルをフォーマットすることができます。xml-descriptionが承認された後、プロジェクトは 簡単に並列化することができます。1) コンポーネントの実装。=>出力はコンポーネントのライブラリです。2) ネットワークタイプ/構造コンフィギュレータ => 出力 - グラフィカル、ステップバイステップまたはその他のコンフィギュレータ、xmlファイルへの設定の保存。3) mqlコードへのトランスレータ（複数可）。=> 出力は、(1) xmlファイルをパラメータとする超ド級の自己設定型mql-neural networkか、 (2) 特定のmqlベースの硬いネットワークへのコンパイラのどちらかです。こんな感じ。理にかなっているようだ。2. うん。 1...555657585960616263646566676869...100 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか？ Googleでログイン
どちらが速いかは明らかです。しかし、トレーニング全体で何回ファイルに書き込む必要があるのでしょうか？- 一度だけ？
そのため、速度は重要ではありませんが、視覚的なコントロールは簡素化されています。
xml-fileなら視覚的にコントロールしやすいとは言えませんね。
それでも何らかのテンプレートをxml-fileとして使うことはできますが、1つのレイヤーに1500個のニューロンがあるグリッドを可視化するのは面倒なので、xml-fileを作る手間がかかり、とにかく良い可視化はできないでしょう。拒否はしませんが、保存すると、xmlでも複製が可能です。
初期化とは どういうことでしょうか？ ウエイトをロードするのであれば、それは一つの方法です。グリッドの設定＋ウェイトの読み込みが別物なら。
--
そうですね。歌います。
中間ネットワークの構成（構造、型）をmql5コードにマッピングする方法は2つあります。
1つ目：初期化時にライブラリクラスからネットワークを動的に設定する。このようなネットワークには、動的な配列や ポインタによるリンクが多く、これまでは暗黙のうちにこの方法が主流でした。
しかし、もう一つの方法があります。それは、事前設定とxmlへのマッピングを行った後、リジッドメッシュ（静的配列と目的のアドレス（インデックス）への直接アクセスを持つ）を生成する方法です。
このようなエンジンは、生成されるグリッドがより高速になるため、ユーザーにとってより魅力的なものになる可能性があります。実際、xml2mqlのコンパイラを作る必要があります。
私は、実は、2つ目の方法に賛成です。 行き詰まったときに、メタ引用が助けになることを願っています。
第一の方法
2番目の選択肢は、（正確には覚えていませんが、最初のページで）破棄されました。なぜなら、将来的に「ユーザー」のカテゴリには、F7が何であるかを知らない人が含まれることになるからです。
また、このエンジンは簡単に拡張できるようになっており、F7の目的を知っている人なら、別の種類のグリッドを追加したり、自分で発明したりすることができます。
ZY テンプレートコーディングへのこだわりは理解できますが、2番目の方法については、学習アルゴリズムの実装とニューロンタイプの拡張の両方に大きな問題があり、さらにGPUに最適化する必要があることに同意します。最初のバリエーション、誰もができる最もシンプルなものには深刻な問題があり、ユニバーサル エンジンのプロジェクトを説明するだけでも頭がパンクしそうです。
明日は、ネットワークプロトタイプの保存、トレーニングタスクの設定、見つかったソリューションの保存などの作業を、仕事場のパソコンからここにコピーします。
すべてxmlで
xmlファイルのパースによるリソース集約は誇張されすぎていると思います。
これは1回限りの処置であることをお忘れなく。
さらに、MQL5用のネイティブなxmlファイルパーサを書くことは、ニューラルネットワークプロジェクトの 複雑さに比べれば、些細なことです。
第一の方法
2つ目の選択肢は、今後、F7が何であるかを知らない人が「ユーザー」に入隊することになるので、（正確には覚えていませんが、最初のページで）破棄されました。
それに、このエンジンは簡単に拡張できるはずで、F7の目的を知っている人なら、自分用にメッシュを追加したり、自分で発明したりすることができます。
メッシュタイプの力量不足で1つだけ質問させてください。
メッシュの種類はルックアップテーブルで一意に定義できるのか、つまり、与えられたルックアップテーブルに従うだけの普遍的な抽象メッシュを作ることはできるのか？つまり、真にユニバーサルな ネットワークということでしょうか。
もし答えが「はい」なら、グリッドタイプは中間ビューが作成される前に グリッド構成エディターで定義され、ユニバーサルライブラリの修正は必要ありません。つまり、グリッド構造がどうであれ、（不具合がなければ）決して必要ない。 できることといえば、最適化、非線形コンバータやトレーニング方法などのライブラリの拡張くらいだろう。
もし「いいえ」なら、この方法に当てはまらない例外について、自由にリンクを貼ってください。
--
ネットワーク記述のxml表現が徹底的に考え抜かれ、mql実装から完全に抽象化されている（これは正しい）なら、代替案は矛盾していないように見えます。どちらも実装可能なだけでなく、必要に応じて相互乗り入れも可能です。
...
答えは二者択一ではありません。
一方では否定的な答えもある。リレーションシップテーブル自体には、ニューロンのタイピングは指定されていないのだ。
一方、答えは肯定的で、数値で型を指定することも可能です（共通の祖先から継承した特定の型のオブジェクトをスイッチで作成します）。
つまり、全体としては、パラメトリック配列とリレーションシップテーブルで問題ないのです。
しかし一方で、コンフィギュレーションエディターにもパラメータ（層数、各層のニューロン数、層のニューロンの種類）があり、それはリンクを作成する前のものです。
つまり、真にユニバーサルな ネットワークということでしょうか。
フィードフォワードから、ですね。その他は、トポロジーを見る必要があります。
トポロジーはリンケージテーブルによって設定される......。
?
トポロジーはリンケージ・テーブルで設定される・・・。
そして、連動させる部品の機能。
よし、ここでもう少し詳しく説明しよう。
この機能は有限の（小さな）表で与えられるか？ 異なるタイプのニューロン（活性化関数は別として）の違いは何か？
よし、ここでもう少し詳しく説明しよう。
この機能は有限の（小さな）テーブルで与えられるのか？ 異なるタイプのニューロン（活性化関数は別として）の違いは何か？
厳密には、そうではありません。
まず簡単なケースを紹介します。例えば、リニア、シグモイド、タンジェントのニューロンがあるとします。新しいタイプのアクティベーションを追加したい場合は、アクティベーションタイプの列挙を拡張する必要があります。
基本的に、だからどうした。その前に、例えばKohonenネットワークでは、なぜ出力層にsome=someの活性化関数の符号が必要なのでしょうか？これは余分な冗長な情報です。
第二に、このリストは理論上、無制限である。
第三に、ネットワークごとに運用や配置に特殊性がある場合があります。例えば、コホネンネットワーク（SOM）では、近傍関数の設定と、結果を出力として出力するか、リーダのみ（リーダ以外をゼロにする）かのフラグを設定することが可能です
例えば、論理モデルでは、設定可能なパラメータは活性化関数にある。これは一般的なモデルにもあるのでしょうか？
MLP層では、単一のニューロン存在フラグである可能性があります。
____________________________
ところで、バイナリ表現よりもxmlの方が妥当性をチェックしやすい。また、保存・復元は基本的にタイムクリティカルではありません。
1. 厳密には、ありません。
まず簡単なケースを紹介します。例えば、リニア、シグモイド、タンジェントのニューロンがあるとします。新しいタイプのアクティベーションを追加したい場合は、アクティベーションタイプの列挙を拡張する必要があります。
基本的には、だからどうした、ということです。その前に、例えばKohonenネットワークでは、なぜ出力層にsome=someの活性化関数の符号が必要なのでしょうか？これは不必要で余分な情報です。
第二に、このリストは理論上、無制限である。
第三に、ネットワークはそれぞれ運用や構造に特殊性がある場合があります。例えば、コホネンネットワーク（SOM）では、近傍関数の設定と、結果を出力として出力するか、リーダのみ（リーダ以外をゼロにする）かのフラグを持つことができる。
例えば、論理モデルでは、設定可能なパラメータは活性化関数にある。これは一般的なモデルにもあるのでしょうか？
MLP層では、1つのニューロンを持つことがフラグとなる可能性があります。
____________________________
2. ちなみに、xmlはバイナリ表現に比べ、妥当性のチェックが非常に容易です。また、Saving Recoveryは基本的にタイムクリティカルではありません。
1. なぜダメな のか私のアイデアは次のようなものです。普遍的な「要素ベース」を作り、そこからあらゆるタイプのニューラルネットワークを「ハンダ付け」できるようにすることです（拡張可能である可能性もあります）。このベースの要素は、厳密で曖昧さのない定義、つまり数式で定義されます。必要に応じて、擬似コードの応用で。しかし、実装から切り離すために、mql-codeの形ではなく、時間と共に改善することができます。 抽象的な要素ベースを作成した後（可能であれば）、要素間のすべての接続を記述できるxml-ファイルをフォーマットすることができます。xml-descriptionが承認された後、プロジェクトは 簡単に並列化することができます。
1) コンポーネントの実装。=>出力はコンポーネントのライブラリです。
2) ネットワークタイプ/構造コンフィギュレータ => 出力 - グラフィカル、ステップバイステップまたはその他のコンフィギュレータ、xmlファイルへの設定の保存。
3) mqlコードへのトランスレータ（複数可）。=> 出力は、(1) xmlファイルをパラメータとする超ド級の自己設定型mql-neural networkか、 (2) 特定のmqlベースの硬いネットワークへのコンパイラのどちらかです。
こんな感じ。理にかなっているようだ。
2. うん。