"New Neural "は、MetaTrader 5プラットフォーム用のオープンソース・ニューラルネットワークエンジンプロジェクトです。 - ページ 68 1...616263646566676869707172737475...100 新しいコメント yu-sha 2011.11.28 13:33 #671 "reverse "は適応的な引数によってフィットネス関数の偏導関数を求めるために必要なもので、したがって、どんな勾配法（例えば、あらゆる修正におけるBackProp）も "reverse "を必要とします。他の方式では必要ない Alexey 2011.11.28 14:27 #672 少し補足させてください。エンドユーザーとして、私はブラックボックスから次のことを必要としています。最後の20-1000本のバー、数個のシンボルを入れました。それに対してブラックボックスはこう言います。最後の15小節で安定したクラスタ状態（フラット）が観察される。これらのクラスタは、1995年1月1日から95年1月20日までの歴史的期間にあります。クラスターの寿命は、最小で20本、最大で74本、平均で47本で、歴史上125回観測されています。推奨される戦略は、チャンネルの境界線から取引することです。チャンネルのレベルは1.2567-1.2687です。あるいは最後の65小節で安定したクラスタ状態（フラット）が観察される。 これらのクラスタは、1995年1月1日から95年1月20日などの履歴期間であるため、グラフを強調することができます。クラスタの最小寿命20バー、最大74バー、平均47バー、全体の歴史は125回観測されました。推奨戦略はチャネルを突破することで、チャネルレベルは1.2567-1.2687です。 今、頭を悩ませているところです。NSでも可能です。 Документация по MQL5: Стандартные константы, перечисления и структуры / Торговые константы / Свойства ордеров www.mql5.com Стандартные константы, перечисления и структуры / Торговые константы / Свойства ордеров - Документация по MQL5 Mykola Demko 2011.11.28 14:53 #673 yu-sha さん。"reverse "は適応的な引数によってフィットネス関数の偏導関数を求めるために必要なもので、したがって、どんな勾配法（例えば、あらゆる修正におけるBackProp）も "reverse "を必要とします。他の方式では必要ありません。ウェイト調整のためのフォワードムーブというのはないと考えていいのでしょうか？であり、学習で前進を用いるアルゴリズムでは、実際には複数の（並列に存在する）重み配列を用いている。 その中から最適なものを選ぶことでそれとも、直接ストロークでウェイトを調整するようなアルゴリズムがまだあるのでしょうか？ yu-sha 2011.11.28 15:29 #674 ウラン です。目盛りの素直なストローク調整というのはないと考えていいのでしょうか？前方移動を用いるアルゴリズムでは、実際には複数の（並列に存在する）重み付けアレイを学習で使用する。 その中から最適なものを選ぶことではい、その通りです。あえてもっと難しく言うと、天秤の調整も後ろからストロークするようなことはありません。"逆ストローク "とは、複雑な関数の微分を求める過程を私たちが視覚的に認識することであり、その本質はニューラルネットワークである学習はネットワーク自体の外部にあるプロセスである学習方法の違いにより、ネットワークのトポロジーや推定される関数の形式に対する要求も異なる勾配法は最も厳しい、確率法は雑食性 TheXpert 2011.11.28 15:53 #675 声を大にして思うこと・・・。この形式のプロジェクトは、ほぼ絶望的だと私は考えています。まず、みんながそれぞれの方向に引っ張っていくからです。プロジェクトにすべてを任せてしまいたい人、プロジェクトにトポロジーそのものを組み立ててほしい人、すべてを第3の空間を目標に飛んでほしい人。2つ目は、操作に対する誤解からです。3つ目は、おそらく最も重要なことですが、これまでのプロジェクトの目標が明確でなかったからです。___________________________とにかく、考え出したのは、「本当に必要なのか？エコーネットワークは、別プロジェクトとして割り切って推進したほうがいいですね。世界征服の計画ではなく、機能的で効果的。では、頑張ってください。このプロジェクトが永久になくならないことを願っています。___________________________何か間違っていたらごめんなさい。 yu-sha 2011.11.28 16:04 #676 TheXpert です。思いを声に出して...。 MetaQuotesのガイディングハンドが絶対必要 Vladimir Kustikov 2011.11.28 16:32 #677 TheXpert: 声を大にして思うこと・・・。この形式のプロジェクトは、ほぼ絶望的だと私は考えています。まず、みんながそれぞれの方向に引っ張っていくからです。プロジェクトにすべてを任せてしまいたい人、プロジェクトにトポロジーそのものを組み立ててほしい人、すべてを第3の空間を目標に飛んでほしい人。2つ目は、操作に対する誤解からです。3つ目は、おそらく最も重要なことですが、これまでのプロジェクトの目標が明確でなかったからです。___________________________とにかく、考え出したのは、「本当に必要なのか？エコーネットワークは、別プロジェクトとして割り切って推進したほうがいいですね。世界征服の計画ではなく、機能的で効果的。では、頑張ってください。このプロジェクトが永久になくならないことを願っています。___________________________何か間違っていたらごめんなさい。一般的に、オープンソースプロジェクトは どのように実装されているのでしょうか？通常、すべてはエンジンを書き、プロジェクトの基本的なイデオロギーを開発する一人のエバンジェリスト（想定外のトーバルズ）から生まれます。そして、プロジェクトが拡大するにつれて、最終的な結果に関心を持つ新しい勢力が加わってくる。そしてここで、ゼロからのスタートであることが判明し、方向性が見えない、方向性がないからです。最良の選択肢は、一人で開発を試みるか、地理的に離れていない非常に緊密なチームで開発することです。そして、そのエンジンが面白くなれば、人々は手に取ってくれるでしょう。この状況で生き残れるのは、この選択肢しかないと思います。 Mykola Demko 2011.11.28 16:38 #678 TheXpert: 声を大にして思うこと・・・。アンドレイ 1つの支店で3つのプロジェクトを 行うことは、誰も止めないよ。実際にはすべてのブランチが同じものを扱っているので、1つのブランチ内で解決策を公開し、共有することができれば便利でしょう。これで、コード生成、異なる実装のプラグイン化、ユニバーサルエンジンの3つの方向性が揃いました。異なる実装を接続する（それがやりたいこと）ことは、コードジェネレータとユニバーサルエンジンの両方にとって非常に有効です。ユニバーサルエンジンは、コードジェネレーターに有効です。そして、（MQLマスターのような）コードジェネレーターは、エンドユーザーにとっての簡便さとスピード（これらはすべて並列ブランチの最高の資質です）を兼ね備えていますが、どちらの方向にも使えません。混乱を避けるために、GC RR UDという略語を使い、各投稿の略語をタイトルに入れたり、例えばカテゴリーごとに投稿を区別してGC RR UD カラーを使用することもできます。 Alexey 2011.11.28 16:50 #679 吐いてほしいけど、無視されるだけだし。イエスかノーか、アドバイスを求められたのですね。もし（YES）なら、賢い本を読みに行く。を買ってきて、正しい方向へ蹴ってくれる。 TheXpert 2011.11.28 16:51 #680 Vladix：私の考えでは、この状況で生き残れる唯一の選択肢だと思います。 ありがとうございます :) 最終ポカウラン です。これで、コード生成、異なる実装の接続、ユニバーサルエンジンの3方向が揃いました。むしろ、1つの実装を扱って、完璧に改善することを目指したいですね。規模（ターゲット機能が明確でないタスクのクラス）ではジェネティックスに勝てないかもしれませんが、使用効率や学習効率では...。 1...616263646566676869707172737475...100 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか？ Googleでログイン
"reverse "は適応的な引数によってフィットネス関数の偏導関数を求めるために必要なもので、したがって、どんな勾配法（例えば、あらゆる修正におけるBackProp）も "reverse "を必要とします。
他の方式では必要ない
少し補足させてください。
エンドユーザーとして、私はブラックボックスから次のことを必要としています。
最後の20-1000本のバー、数個のシンボルを入れました。
それに対してブラックボックスはこう言います。最後の15小節で安定したクラスタ状態（フラット）が観察される。
これらのクラスタは、1995年1月1日から95年1月20日までの歴史的期間にあります。
クラスターの寿命は、最小で20本、最大で74本、平均で47本で、歴史上125回観測されています。
推奨される戦略は、チャンネルの境界線から取引することです。チャンネルのレベルは1.2567-1.2687です。
あるいは
最後の65小節で安定したクラスタ状態（フラット）が観察される。
これらのクラスタは、1995年1月1日から95年1月20日などの履歴期間であるため、グラフを強調することができます。
クラスタの最小寿命20バー、最大74バー、平均47バー、全体の歴史は125回観測されました。
推奨戦略はチャネルを突破することで、チャネルレベルは1.2567-1.2687です。
今、頭を悩ませているところです。NSでも可能です。
"reverse "は適応的な引数によってフィットネス関数の偏導関数を求めるために必要なもので、したがって、どんな勾配法（例えば、あらゆる修正におけるBackProp）も "reverse "を必要とします。
他の方式では必要ありません。
ウェイト調整のためのフォワードムーブというのはないと考えていいのでしょうか？
であり、学習で前進を用いるアルゴリズムでは、実際には複数の（並列に存在する）重み配列を用いている。
その中から最適なものを選ぶことで
それとも、直接ストロークでウェイトを調整するようなアルゴリズムがまだあるのでしょうか？
目盛りの素直なストローク調整というのはないと考えていいのでしょうか？
前方移動を用いるアルゴリズムでは、実際には複数の（並列に存在する）重み付けアレイを学習で使用する。
その中から最適なものを選ぶことで
はい、その通りです。
あえてもっと難しく言うと、天秤の調整も後ろからストロークするようなことはありません。
"逆ストローク "とは、複雑な関数の微分を求める過程を私たちが視覚的に認識することであり、その本質はニューラルネットワークである
学習はネットワーク自体の外部にあるプロセスである
学習方法の違いにより、ネットワークのトポロジーや推定される関数の形式に対する要求も異なる
勾配法は最も厳しい、確率法は雑食性
声を大にして思うこと・・・。
この形式のプロジェクトは、ほぼ絶望的だと私は考えています。
まず、みんながそれぞれの方向に引っ張っていくからです。プロジェクトにすべてを任せてしまいたい人、プロジェクトにトポロジーそのものを組み立ててほしい人、すべてを第3の空間を目標に飛んでほしい人。
2つ目は、操作に対する誤解からです。
3つ目は、おそらく最も重要なことですが、これまでのプロジェクトの目標が明確でなかったからです。
___________________________
とにかく、考え出したのは、「本当に必要なのか？エコーネットワークは、別プロジェクトとして割り切って推進したほうがいいですね。
世界征服の計画ではなく、機能的で効果的。
では、頑張ってください。このプロジェクトが永久になくならないことを願っています。
___________________________
何か間違っていたらごめんなさい。
思いを声に出して...。
声を大にして思うこと・・・。
この形式のプロジェクトは、ほぼ絶望的だと私は考えています。
まず、みんながそれぞれの方向に引っ張っていくからです。プロジェクトにすべてを任せてしまいたい人、プロジェクトにトポロジーそのものを組み立ててほしい人、すべてを第3の空間を目標に飛んでほしい人。
2つ目は、操作に対する誤解からです。
3つ目は、おそらく最も重要なことですが、これまでのプロジェクトの目標が明確でなかったからです。
___________________________
とにかく、考え出したのは、「本当に必要なのか？エコーネットワークは、別プロジェクトとして割り切って推進したほうがいいですね。
世界征服の計画ではなく、機能的で効果的。
では、頑張ってください。このプロジェクトが永久になくならないことを願っています。
___________________________
何か間違っていたらごめんなさい。
一般的に、オープンソースプロジェクトは どのように実装されているのでしょうか？
通常、すべてはエンジンを書き、プロジェクトの基本的なイデオロギーを開発する一人のエバンジェリスト（想定外のトーバルズ）から生まれます。そして、プロジェクトが拡大するにつれて、最終的な結果に関心を持つ新しい勢力が加わってくる。そしてここで、ゼロからのスタートであることが判明し、方向性が見えない、方向性がないからです。最良の選択肢は、一人で開発を試みるか、地理的に離れていない非常に緊密なチームで開発することです。そして、そのエンジンが面白くなれば、人々は手に取ってくれるでしょう。この状況で生き残れるのは、この選択肢しかないと思います。
声を大にして思うこと・・・。
アンドレイ 1つの支店で3つのプロジェクトを 行うことは、誰も止めないよ。
実際にはすべてのブランチが同じものを扱っているので、1つのブランチ内で解決策を公開し、共有することができれば便利でしょう。
これで、コード生成、異なる実装のプラグイン化、ユニバーサルエンジンの3つの方向性が揃いました。
異なる実装を接続する（それがやりたいこと）ことは、コードジェネレータとユニバーサルエンジンの両方にとって非常に有効です。
ユニバーサルエンジンは、コードジェネレーターに有効です。そして、（MQLマスターのような）コードジェネレーターは、エンドユーザーにとっての簡便さとスピード（これらはすべて並列ブランチの最高の資質です）を兼ね備えていますが、どちらの方向にも使えません。
混乱を避けるために、GC RR UDという略語を使い、各投稿の略語をタイトルに入れたり、例えばカテゴリーごとに投稿を区別してGC RR UD カラーを使用することもできます。
吐いてほしいけど、無視されるだけだし。イエスかノーか、アドバイスを求められたのですね。
もし（YES）なら、賢い本を読みに行く。
を買ってきて、正しい方向へ蹴ってくれる。
ウラン です。
これで、コード生成、異なる実装の接続、ユニバーサルエンジンの3方向が揃いました。
むしろ、1つの実装を扱って、完璧に改善することを目指したいですね。
規模（ターゲット機能が明確でないタスクのクラス）ではジェネティックスに勝てないかもしれませんが、使用効率や学習効率では...。